Why your software partner needs to be laser focused on product launch

Innovation is key to staying ahead of the competition in the software world. The process of developing and launching software - fast, on time, and on budget, is crucial for a company's success. That is why when a company is planning to build software, one of the most critical decisions a company must make is selecting a vendor with a proven track record of delivering projects on time and within budget. However, the benefits go beyond just meeting deadlines and financial constraints. Choosing a vendor with a pragmatic approach to software release, emphasizing early launches and incremental improvements, can be a game-changer for your project.

The Pitfalls of Delayed Launches

1. Increased Risk of Failure

One of the primary reasons to prioritize on-time delivery is to mitigate the risk of project failure. Sometime back we wrote a great post about why software projects fail and how to save them. It’s worth repeating some of the data from that post. The CHAOS reports published by the Standish Group is a study of software projects in a wide range of industries and countries. The CHAOS Reports have been published every year since 1994 and are great indicators of the state of the software space.  The 2015 report studied more than 50,000 projects around the world, ranging from small software projects to huge ones.  The results show clearly the trend that software projects are failure-prone. Take the summary pie charts in the report (shown below). The red is ominously present in all the three aspects that were judged - budget overflows, timely delivery, and feature achievement. In a more recent study, Gartner found that 45% of software projects get delayed by at least a month. So delayed launch is a real and present danger.

The longer a software project takes, the more likely it is to encounter unforeseen challenges, such as changes in market conditions, shifts in technology trends, or internal organizational changes. By adhering to a timely release schedule, a company minimizes exposure to these risks and ensures that its software remains relevant and effective in the ever-evolving business landscape.

2. Getting Features Right the First Time

Launching early and iterating allows for the immediate validation of core features. When a company delays its software release in favor of an extensive development cycle, there is a higher likelihood of investing time and resources in features that may not align with user needs or market demands. By releasing software in phases, companies can gather real user feedback early on, enabling them to make informed decisions about the direction of the project and refine features based on actual user experiences.

3. Early User Feedback is Invaluable

In the world of software development, user feedback is gold. Launching early allows companies to put their product in the hands of real users, gaining insights into its strengths and weaknesses. This early feedback loop is invaluable for making informed adjustments, identifying potential issues, and ensuring the software meets user expectations. Delaying the launch deprives companies of this critical input, potentially leading to costly revisions after a full-scale release.

The Pragmatic Approach to Software Development

1. Launch Early, Launch Often

A vendor with a pragmatic view on software development understands the importance of launching early and iterating frequently. This approach not only reduces the time-to-market but also allows companies to establish a presence in the market sooner, gaining a competitive advantage. Moreover, it creates a continuous improvement cycle where features are refined based on real-world usage, making the software more responsive to user needs.

The release early, release often philosophy in software has proven time and time to work. This philosophy was popularized by Eric S. Raymond in his 1997 essay The Cathedral and the Bazaar, where Raymond stated "Release early. Release often. And listen to your customers".

2. Incremental Improvements Foster Innovation

Rather than aiming for a massive, all-encompassing release, a vendor focused on incremental improvements encourages a culture of innovation. By breaking down the software into manageable phases, companies can prioritize key functionalities and respond to changing requirements or market dynamics more effectively. This flexibility is paramount in a landscape where adaptability is synonymous with success.

3. Cost-Effective and Predictable Development

Choosing a vendor with a track record of delivering software on time and budget ensures a more predictable and cost-effective development process. This not only protects the company's financial investments but also allows for better resource planning and allocation. Predictable timelines facilitate clearer communication with stakeholders, instilling confidence in the project's progress.

Choose your software partner well

The decision to choose a vendor with a proven track record of delivering software on time and budget, coupled with a pragmatic approach to release cycles, can significantly impact the success of a software project. Embracing a philosophy of launching early and iterating with incremental improvements not only reduces the risk of failure but also facilitates early user feedback, ensuring that the software aligns with market needs and user expectations. In the ever-evolving landscape of technology, a company's ability to adapt and innovate is directly linked to its approach to software development. Therefore, the careful selection of a vendor with a commitment to timely delivery and iterative improvement is a strategic investment that pays dividends in the long run.

Do you have a software project that you need delivered on time and on budget?

Contact us, we have a 20+ year track record of delivering software on time and on budget and we don’t want to break that record anytime soon!

Staff Augmentation vs. Project-Based Consultancy—Which One Wins?

Bringing in an agency to help build your software platform is a winning strategy - it saves you time, and stress and most importantly keeps you within budget. But businesses often find themselves at a crossroads when it comes to outsourcing solutions. Two popular options—Staff Augmentation and Project-Based Consultancy—offer distinct advantages and cater to different needs. Let's delve into the intricacies of each approach and explore the benefits they bring to the table.

Staff Augmentation: Unleashing Flexibility and Scaling Capabilities

Staff augmentation in software projects refers to the practice of supplementing an existing in-house development team with external, temporary personnel or skilled professionals. This external workforce, often provided by an outsourcing or staffing agency, integrates seamlessly into the client's team to contribute specific expertise, skills, or resources needed for a particular project.

Staff augmentation strategy has a lot going for it, here are some big ones:

1. Greater Control and Flexibility:

Staff Augmentation is a go-to choice for businesses requiring temporary skilled workers or dealing with short-term projects. It provides greater control over the team, allowing seamless integration with in-house operations. The flexibility to scale the team up or down ensures that resources align with project requirements.

2. Immediate Access to Skilled Resources:

One of the standout advantages of staff augmentation is the swift access to a pool of skilled professionals. This is particularly beneficial for projects with tight deadlines, enabling teams to hit the ground running without the delays associated with traditional hiring processes.

3. Cost-Effectiveness for Short-Term Needs:

Staff Augmentation can be a cost-effective solution for short-term projects. While long-term costs may accumulate, the ability to bring in expertise only when needed can be a strategic financial decision.

4. Integration with Existing Processes:

Augmented staff seamlessly follow existing tools and processes within your company. This ensures a smooth workflow and integration with established methodologies, enhancing productivity.

5. Skill Enhancement for Ongoing Plans:

Ideal for developers familiar with project goals but needing extra support, staff augmentation aids in executing ongoing plans to scale. It provides knowledge of industry best practices and can contribute to achieving long-term objectives.

Project-Based Consultancy: Precision, Expertise, and Defined Outcomes

Project-based consultancy strategy in software projects involves engaging external consultants or consulting firms to provide expert guidance, strategic planning, and hands-on implementation for specific projects within a defined scope. Unlike staff augmentation, where external resources integrate into the existing team, project-based consultancy is more focused on delivering a comprehensive solution or achieving specific project goals.

Just like staff augmentation strategy, project-based consultancy has it’s upsides, here are some:

1. Expert Guidance and Implementation:

Project-Based Consultancy shines when businesses seek expert guidance and execution for specific projects. Consultants bring in-depth knowledge and experience, offering valuable insights that can elevate the project to market standards.

2. Defined Outcomes and Timelines:

Unlike staff augmentation, project-based consulting operates on a fixed or project-based cost structure. This clarity in financials and a clearly defined scope and timeline make it easy for businesses to budget and plan effectively.

3. Strategic Roadmap and Industry Compliance:

Project-based consultants provide strategic guidance in uncharted territories, ensuring adherence to industry compliance standards. They bring a fresh perspective, introducing efficiency to development processes and paving the way for successful project delivery.

4. Specialized Skills for New Challenges:

Consultants are aptly equipped to introduce businesses to new challenges. Whether it's accessing a new consumer platform or venturing into a new field, project-based consultancy helps enterprises apply their core talents to diverse and unfamiliar scenarios.

5. High Security Standards:

Consultants are expected to adhere to stringent security standards, providing a high level of data security. Their commitment to industry best practices ensures that projects meet the necessary privacy and security requirements.

Here’s the interesting thing, it doesn’t have to be one of those options! You could actually mix them up to bring out the best of both worlds.

Strength in Combination: A Holistic Approach

These two approaches need not be mutually exclusive. At Kaz we have have done many software projects where we have had both a dedicated team of developers working with our clients as part of their core team and separate parts of the system being built at the same time for that client in project based format. This gives our clients the flexibility and cost-control at the same time getting the benefits of the dedicated team. The added benefit of such a combined approach is that a component delivered as part of a project based work can then be looked after by the dedicated resource team (augmented staff) that has the benefit of co-located with the project team. This makes solving issues, knowledge transfer, future extension fast and accurate.

Also, initiatives that start as project-based consulting may evolve into more hands-on commitments, and vice versa. The combined strength of IT staff augmentation and project-based consultancy can lead to enhanced product responsibility, end-to-end support, and ongoing intellectual property advantages.

Code Reuse: Leveraging the Goldmine

Here’s a little fun comic we did a long time ago in Bangla, roughly translated it says, “Copy paste was designed by the programmers for themselves!” This was fun but there is an element of fundamental truth about this. Code reuse is one of the best practices in the software world if done right.

The importance of efficiency, speed, and cost-effectiveness cannot be overstated. As developers strive to meet tight deadlines and deliver high-quality products, the strategy of reusing existing software code has emerged as a powerful tool. In this blog, we'll delve into the myriad benefits of leveraging pre-existing code and explore how this practice contributes to the success of software development projects.

1. Accelerated Development Cycles:

One of the primary advantages of reusing existing code is the acceleration of development cycles. Instead of reinventing the wheel for every project, developers can draw upon the wealth of code libraries and frameworks available. This not only reduces the time required for coding but also allows teams to focus on the unique aspects of their project, leading to faster time-to-market.

2. Cost Efficiency:

Time is money, and in the world of software development, time spent on coding directly impacts costs. By reusing existing code, developers can significantly cut down on development time, resulting in cost savings. Additionally, leveraging open-source software and libraries eliminates the need to develop certain functionalities from scratch, reducing overall project expenses.

3. Quality Assurance:

Well-established, reused code has likely undergone rigorous testing and debugging. When incorporating existing code into a new project, developers benefit from the collective efforts of the original contributors, reducing the likelihood of bugs and errors. This enhances the overall reliability and robustness of the software, leading to a more stable end product.

4. Consistency and Standardization:

Reusing code promotes consistency and standardization across projects. Adopting a standardized set of libraries or frameworks ensures that developers adhere to best practices and coding conventions, resulting in cleaner, more maintainable code. This consistency simplifies collaboration among team members and facilitates knowledge transfer within the organization.

5. Community Support and Innovation:

Open-source communities thrive on collaboration and shared innovation. By reusing existing code from open-source projects, developers tap into a vast pool of knowledge and expertise. Community support can be invaluable when troubleshooting issues or seeking advice on implementation, fostering a culture of continuous learning and improvement.

6. Scalability:

Reusable code is inherently scalable. As project requirements evolve or expand, developers can seamlessly integrate new functionalities by building upon existing, proven codebases. This scalability not only streamlines the development process but also ensures that the software remains adaptable to changing business needs.

In the dynamic realm of software development, the value of reusing existing code cannot be overstated. Accelerating development cycles, reducing costs, ensuring quality, promoting consistency, and tapping into community innovation are just a few of the benefits that come with this strategic approach. By embracing the principle of code reuse, developers position themselves to not only meet the demands of today but also to adapt and thrive in the challenges of tomorrow. It's not just about writing code; it's about leveraging the collective intelligence of the developer community to build a more efficient and sustainable future for software development.

Why should you use an agency to build your software?

In today's fast-paced and highly competitive business environment, companies need to continuously improve their operations and processes to stay ahead. One way to do this is by leveraging technology and software to automate and streamline various functions. However, not all businesses have the in-house expertise or resources to develop and maintain software solutions on their own. This is where software development agencies come in - they offer a range of services to help businesses create, implement and maintain software solutions that meet their specific needs. In this blog, we will discuss the benefits of using a software development agency.

Cost-effective

One of the biggest advantages of using a software development agency is cost savings. Hiring and training an in-house team of software developers can be costly, time-consuming, and risky. By outsourcing software development to an agency, businesses can save on salaries, benefits, training, and infrastructure costs. Surveys show the cost-effectiveness of using an agency in low cost software destinations such as Bangladesh but even if you are not going offshore using an agency close to you will bring down your costs by reducing your HR commitments along with the cost of operation.

Expertise and Experience

Software development agencies have a team of experts who have extensive experience in developing software solutions for different industries and use cases. They have worked on various projects and have the necessary skills, knowledge, and tools to create effective solutions quickly and efficiently. They also keep up-to-date with the latest trends and technologies in the industry, so businesses can benefit from the latest innovations and advancements. By hiring an agency in essence you are getting access to their entire skillset and expertise on a need basis, a great example is how we help our software customers with a design team when they need to create visualization of their ideas - the design team comes in for a short time to turn the ideas into mockups and specifications that the software team can use as their guide. The cost to the clients is minimal, yet the benefit is a dedicated design and product team that only giant companies can afford.

Faster Time to Market

Software development agencies have streamlined processes and workflows that enable them to develop and deploy software solutions faster than an in-house team. They have experience working on different projects and can quickly adapt to changing requirements and timelines. This means businesses can launch their products or services faster and gain a competitive advantage.

Scalability

A software development agency can scale its resources and expertise based on a business's needs. This means that as a business grows, the agency can provide additional resources and support to meet the increasing demands for software development services. Similarly, if a business needs to downsize or reduce its software development needs, the agency can adjust its resources accordingly.

Focus on Core Competencies

By outsourcing software development to an agency, businesses can focus on their core competencies and strategic initiatives. This means that they can allocate their resources and attention to activities that are critical to their success, such as product development, marketing, sales, and customer service. Software development becomes a supporting function rather than a core competency.

Using a software development agency has many benefits for businesses looking to develop custom software solutions. It can help businesses save on costs, access expertise and experience, launch products faster, scale resources as needed, and focus on core competencies. Businesses should carefully evaluate their software development needs and choose an agency that can meet their requirements, deliver high-quality solutions, and provide ongoing support and maintenance. By doing so, they can reap the benefits of technology and stay ahead of the competition.

Outsource with confidence: 7 Essential Practices for Software Development Success

In the fast-paced realm of technology, the decision to outsource software development can be a game-changer for your business. Whether you're brimming with a brilliant app idea or seeking to revamp your existing one, outsourcing can provide the expertise and bandwidth you need without the hassle of managing an in-house development team. Bangladesh, where we are based is a major hub for outsourced software development projects, and there are really good reasons to outsource here. So over the past 20 years of working with companies from all over the world, we’ve picked up some good tips and tricks about how best to run an outsourced software project. Before embarking on the quest for the perfect development partner, it's crucial to familiarize yourself with the best practices that can shape a successful outsourcing journey. Here are seven key principles to guide you through the process:

1. Define Your Reasons for Outsourcing

Before diving into the outsourcing pool, introspect on the reasons driving your decision. Ask yourself, "Do I really need to outsource?" Clearly identify the factors pushing you towards this choice and create a reference list. This introspection will serve as a compass, steering you through the outsourcing process, and aiding decision-making. Ensure that your project is suitable for outsourcing, particularly when specialized expertise, additional support, or time constraints are significant factors. A great read along these lines is this post about finding the right balance for outsourcing parts of your software projects.

2. Choose the Right Partner

Selecting a reliable outsourcing partner is paramount to the success of your project. Look for a company with a stellar reputation and a proven track record of delivering results. While peer recommendations and reviews are invaluable, delve deeper into compatibility. Assess whether the partner's work culture aligns with yours, and if their working hours and communication methods suit your preferences.

3. Look Beyond Cost

While cost efficiency is a driving force behind outsourcing decisions, it should never be the sole consideration. Prioritize the quality of the end product during the selection process. Ensuring that you receive a high-quality solution is essential, even if it means investing a bit more upfront.

4. Thoroughly Scope Your Project

A detailed project scope is the cornerstone of successful outsourcing. Use this as a trial project if you're in doubt about a potential partner. Provide a comprehensive project scope to align everyone's expectations and establish a procedure for handling additional work outside the initial scope. Prevent project delays caused by incessant feature additions and requests.

5. Establish Robust Communication Channels

Effective communication is the backbone of any successful outsourcing venture. Implement strong communication channels to facilitate seamless interaction with the development team. While multiple channels like Slack, email, messengers, Skype, telephone, screensharing tools, and issue trackers may be available, designate a primary channel for efficiency and clarity.

6. Stay Actively Involved

Outsourcing doesn't imply a hands-off approach. Stay engaged with the development process by checking in on progress regularly. Understand the team's requirements for resources and provide necessary input to keep the project on track. Take ownership of the process for optimal results.

7. Embrace Task Management Tools

Regardless of your project's scale or complexity, task management is non-negotiable. Implement a project management or task management system to monitor development progress. This helps you track tasks, understand the pace of development, and identify potential roadblocks in collaboration with your outsourcing partner.

Outsourcing software development can be a strategic move for meeting your company's needs, but success is not guaranteed without a thoughtful approach. This list serves as a foundational guide, emphasizing the importance of selecting the right partner and establishing processes that enhance the likelihood of successful outsourcing. Explore our additional tips and tricks for selecting software vendors to further refine your outsourcing strategy.

Strategies to Avoid Analysis Paralysis in Software Development

Embarking on the profound journey of software development, one is quickly confronted with an elemental truth: there is no singular answer to any problem. This revelation, cultivated over years spent traversing the intricate landscape of algorithms, architectures, and enterprise platforms, is a foundational tenet of a seasoned software practitioner's wisdom. In this exploration, we delve into an extensive array of strategies, tips, and insights accumulated over decades to avoid the notorious pitfall known as "Analysis Paralysis"—a condition that has the potential to stifle innovation and progress within the realm of software development.

Analysis paralysis (or paralysis by analysis) describes an individual or group process where overanalyzing or overthinking a situation can cause forward motion or decision-making to become "paralyzed"…

Diverse Solutions, Diverse Perspectives: The Essence of Software Problem-Solving

The very essence of software problem-solving lies in the acknowledgment of the myriad ways one can arrive at a solution. Whether grappling with the intricacies of a simple algorithm or sculpting the blueprint for a sophisticated enterprise platform, every problem unfolds a cornucopia of potential solutions, each laden with its unique set of advantages and drawbacks. The challenge transcends merely finding "A Solution"; it involves navigating through the labyrinth of alternatives without succumbing to the pitfalls of perpetual analysis. The software development landscape is, at times, besieged by the affliction known as "Analysis Paralysis," wherein teams become ensnared in the web of alternatives, often resulting in indecision or, worse, a protracted stalemate leading to time depletion.

Ego: The Silent Saboteur in Software Development

The cardinal rule that stands as a beacon amid the complexities of software development is the imperative to divorce personal ego from professional discussions. Ego, oftentimes the silent saboteur, emerges as the biggest impediment to progress. The ability to detach oneself from ideas becomes a hallmark of seasoned developers. It is not about defending one's ego; it is about finding solutions. The moment discussions devolve into personal defenses, the focus shifts from the noble pursuit of creating value to the counterproductive endeavor of preserving one's ego—an unfruitful detour that hampers collaborative innovation. We are big fans of Ryan Holiday’s book about Ego - Ego is the Enemy

We are such big fans of the book that we have also made a video about it our books that software developers must read series in Bangla.

Standing on the Shoulders of Giants: Leverage Collective Knowledge

Design Patterns: Elements of Reusable Object-Oriented Software

By Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

In a domain where problems often recur, acknowledging that others may have already navigated similar challenges is paramount. Leveraging the vast repository of knowledge available online, particularly through platforms like Stack Overflow, becomes a strategic imperative. The power of authoritative voices cannot be overstated; quoting industry giants and referencing proven design patterns can elevate a discussion from a mere exchange of opinions to a collaborative pursuit of well-founded solutions.

"In my view, the Gang of Four is the best book ever written on object-oriented design - possibly of any style of design." — Martin Fowler

The Power of Data: Informed Decision-Making in Software Development

Data, the bedrock of informed decision-making, is abundantly available in the software domain. Harnessing statistical data, survey results, and insights from scientific studies can provide concrete support for proposed solutions. From the impact of developers' seating positions to broader topics like software architecture, relying on reputable data sources becomes instrumental in guiding teams out of the quagmire of analysis paralysis. It transforms decision-making from subjective deliberations to an objective process grounded in empirical evidence.

The Personal Touch: Sharing Experiences as a Catalyst for Understanding

While data adds an objective weight to arguments, the personal touch of shared experiences provides a relatable dimension. Narratives from one's own journey, divested of ego and fortified by precise connections to the current context, can resonate profoundly with the team. Anecdotes become powerful tools when used to illustrate how past experiences align with proposed solutions, fostering a deeper understanding and connection among team members.

Embracing Open-mindedness: The Antidote to Rigidity

Acknowledging the absence of a perfect solution is not a concession but a realization of the dynamic nature of software development. No team can claim perfection, and staying open-minded becomes the linchpin for continuous improvement. An agile approach, marked by skepticism and a readiness to reassess decisions, helps navigate the ever-evolving landscape of software development. The ability to pivot and adapt, even after reaching a conclusion, ensures that teams remain agile and responsive to the multifaceted challenges that arise.

Testing the Waters: Prototyping, A/B Testing, and Surveys

In a realm where certainty is elusive, keeping options flexible is paramount. Teams can employ various strategies to test proposed solutions and mitigate the risk of committing to an unsuitable path:

Prototyping

Creating a low-cost prototype can be instrumental in testing specific functionalities or validating the feasibility of an approach. A quick test project has the potential to provide tangible insights, resolving potential bottlenecks before they become significant obstacles.

A/B Testing

If possible, running low-cost A/B testing can shed light on which of multiple solutions is a better option. By pitting two opposing groups against each other, teams can design low-cost tests to prove or disprove the effectiveness of different approaches.

Surveys

Engaging stakeholders, including customers or other software developers, through surveys can provide valuable external perspectives. Asking for opinions on proposed solutions or seeking feedback on the perceived technical viability can augment the decision-making process.

In the dynamic realm of software development, the ability to navigate through the multitude of solutions is an art. Freeing oneself from the shackles of ego, leveraging authoritative voices, relying on data, sharing experiences, and embracing open-mindedness collectively form a robust toolkit for steering clear of analysis paralysis.

As we continue to evolve in the world of coding, these strategies serve as a compass, guiding us through the maze of possibilities. In the end, it's not just about finding a solution but about embarking on a journey where every road taken contributes to the collective wisdom of the software development community. The software development odyssey is a continuous exploration, where adaptability, collaboration, and a commitment to learning become the sails propelling us forward into the uncharted waters of innovation and excellence.

Software: it's not for you, it's for your customer

The Crucial Art of Understanding Your Customer

In the dynamic landscape of software product development, there's a cardinal rule that often separates the triumphs from the tribulations: understanding your customer. The adage, "Your software is not for you, but for your customers," echoes through the corridors of startup wisdom, serving as a guiding principle for those seeking to navigate the complexities of bringing a digital creation to life.

The Costly Mistake of Losing Sight

Whether you're steering the ship as a startup founder or collaborating within a seasoned product team, losing sight of the end user's needs can prove fatal. It's akin to embarking on a journey without a map; the chances of reaching your destination diminish with each step taken in the dark.

Market Research: Illuminating the Path

Diving headfirst into comprehensive market research is the first beacon of light in this journey. It involves not just studying market trends but engaging directly with potential users. Understand their pain points, desires, and expectations. What keeps them up at night, and what would make their lives easier? These are the questions that form the basis of a foundation strong enough to withstand the tests of time.

Embracing Feedback: The True North

Feedback is the lifeblood of progress. Yet, many developers and founders shy away from it, fearing criticism or divergence from their original vision. This hesitancy is where the downfall begins. Embrace feedback, even the harshest critiques, as they are the keys to unlocking a product's true potential. Users, after all, are the most authentic judges of a product's usability and relevance.

Recognizing and Overcoming Biases

In the quest to create groundbreaking software, acknowledging and overcoming biases is paramount. As creators, we bring our own experiences, preferences, and assumptions to the table. However, these might not always align with the diverse needs of the target audience.

User-Centric Design: A Paradigm Shift

User-centric design is more than just a buzzword; it's a paradigm shift in approach. It involves stepping into the shoes of the end user, understanding their context, and designing a product that seamlessly integrates into their world. This shift challenges preconceived notions and ensures that the final product isn't a reflection of the creator's preferences but a solution tailored to the users' real-world challenges.

Personas: Bringing Users to Life

Creating user personas is a powerful technique to personify the abstract concept of your "customer." It goes beyond demographics, delving into the motivations, frustrations, and aspirations of fictional characters who represent your target audience. By crafting these personas, you build empathy and gain insights that can shape a product into something users don't just need but truly want.

The Process: Tried and Tested

As the saying goes, "To know thy customer is to know thyself." The journey of understanding your customer isn't a linear path but a mosaic of interconnected steps. Here are some key stepping stones:

1. Conduct User Interviews: Schedule one-on-one interviews with potential users. Listen actively, ask probing questions, and seek to understand the intricacies of their daily lives.

2. Utilize Surveys: Surveys are a scalable way to gather information. Craft well-thought-out surveys that touch on pain points, preferences, and user expectations.

3. Iterate Based on Feedback: Your product is not a static entity but an evolving one. Be prepared to iterate based on user feedback. Every critique is a valuable opportunity for improvement.

4. Test Prototypes: Before the full product launch, test prototypes with a select group of users. This provides real-world insights without the risks associated with a wide-scale release.

5. Leverage Analytics: Once your product is in the hands of users, leverage analytics tools to track user behavior. What features are popular? Where do users drop off? Use this data to refine and optimize.

A Warning Against Complacency

The ever-changing landscape of technology demands perpetual adaptability. Understanding your customer isn't a one-time task but an ongoing commitment. As markets evolve and user expectations shift, staying attuned to your customers ensures that your product remains relevant and impactful.

In the symphony of software product development, understanding your customer is the melodic refrain that resonates through every stage. It harmonizes market research, feedback, and user-centric design into a composition that strikes a chord with users. Embrace this cardinal rule, and your venture will not only survive but thrive in the dynamic and competitive realm of software innovation. After all, success in software development is not just about lines of code; it's about understanding the hearts and minds of those for whom the code is written.

Managing a multi-cultural remote software team

Remote work is the new normal, and managers need to be prepared to lead their teams in this new environment. And in today's globalized world, multicultural teams are the common remote teams. Cultural diversity is common in onsite teams too but the issues of miscommunications because of cultural issues are much more complex in remote teams. With the rise of remote work and the desire for flexibility among younger generations, managing a team from different cultural backgrounds has become one of the biggest challenge for managers. And this is an essential skill that all managers are picking up.

Since Kaz is a software development agency based out of Bangladesh and we work mostly with software companies based in the US or Europe. So the very nature of our work leads us to the remote cross cultural issues. And this not a new thing for us because of the recent rise of remote work. We’ve been participating in remote software teams for the past 18 years, and over that long time we’ve probably seen all the things that can go wrong in such cross culture, cross language teams and have devised strategies that solve those issue (or at least reduces to chances of them arising). We’ve also come up with a little poster for expressions in English that doesn’t translate well, that we sometimes give to our customers’ project managers as a cheat-sheet! So, today’s post is a summary of some of our best tips around this and that useful “cross culture expressions to avoid cheat-sheet”.

Understand that there is problem

This is important. Specially in the software world. We sometimes hear things like: “At the end it’s all code, and the language of code is the same so there will be no problem”. Although at the fundamental level that is very true, but to get to that stage of work and collaboration the remote teams still have go through layers of communications. That communications is typically in a language that isn’t a first language for at least one side and sometimes for both sides. And that’s where the start of the problem happens, and layer on top of that the cultural difference and the fact that cultural context changes the meaning of many expressions and mannerisms - you have a problem. So it’s vital for software managers to understand that there is a problem and it will need active strategies and process to solve that problem.

In this context, it is essential to recognize that cultural differences can lead to misunderstandings and conflicts. As the speaker in the video explains, even seemingly simple things like expressions about time can have very different meanings in different cultures. For example, in some cultures, "just now" might mean "in a few minutes," while in others, it might mean "sometime in the future." Without understanding these differences, miscommunications can easily arise, leading to frustration and conflict.

Create culture awareness in the team

To address this challenge of cultural difference and the need to work around such difference, it is important to invest in cultural awareness and sensitivity training for managers and employees. This might involve providing resources such as books or online courses on cross-cultural communication, as the speaker in the video did. It might also involve hosting workshops or training sessions led by experts in intercultural communication.

One key aspect of this training should be the importance of context in communication. As the speaker explains, even when two teams are using the same language, differences in context can lead to misunderstandings. For example, a phrase that might be intended as a compliment in one culture might be interpreted as criticism in another culture. Understanding these differences requires a deep appreciation for the cultural norms and values that shape communication styles in different parts of the world.

Create an environment of trust

Another important aspect of managing a multicultural team is building trust and rapport among team members. When people come from different cultures, they may have different expectations about how to build relationships and establish trust. For example, in some cultures, it may be important to spend time getting to know someone on a personal level before discussing business matters, while in others, business may be the focus from the outset. Understanding these differences can help managers to build stronger relationships with team members and foster a sense of camaraderie and trust.

We’ve written extensively about this in the past, as we feel that this is one that that makes thing much simpler to solve cross cultural issues. Some of our tips can be found in this article about how to build trust in your remote team by team gelling or this one about creating the right team culture for companies with remote teams.

Find what works the best for you

It is important to recognize that managing a multicultural team is not a one-size-fits-all endeavor. Different cultures have different expectations around communication, hierarchy, and decision-making, among other things. Effective managers must be able to adapt to these differences and find ways to accommodate the needs and preferences of each team member. This might involve using different communication tools for different team members, or adjusting work schedules to accommodate different time zones.

Careful about what expressions you use

It's important to be aware that expressions that you might use in your language or cultural context might not be understood at all or even worse understood with the opposite meaning by your remote team. It is vital for team managers (and team members) to consider cultural differences when communicating with people from other backgrounds. It's also a good idea to clarify the meaning of an expression if you think it may be misunderstood. Here’s our list of common English expressions that just doesn’t cross the language and culture basriers well. We call it the expressions to avoid cheat-sheet!

"Break a leg" - This one never works. In most non-English cultures, wishing someone luck by saying "break a leg" is considered bad luck or even offensive. Actually if you think about it really weird that this expression has the meaning it has, here’s the Wikipedia post giving it’s history.

"Bite the bullet" - This expression means to endure a painful or difficult situation, but in some cultures, the literal meaning of biting a bullet can be confusing or offensive.

"Spill the beans" - This expression means to reveal a secret, but in some cultures, the idea of spilling beans may not make sense or may be seen as wasteful. I remember once one of our customers used this expression in the context of asking his team not to reveal software features anyone and the look of confusion in the team was very interesting!

"Piece of cake" - This expression means that something is easy, but it almost always fails to translate well.

"Going Dutch" - This expression means to split the bill, but in some cultures, the idea of going Dutch may be unfamiliar or seen as impolite.

"Skeletons in the closet" - This expression means to have secrets or embarrassing information, but to someone not used to the expression the idea of keeping skeletons in a closet would not make sense at all!

"Costs an arm and a leg" - This expression means that something is very expensive, but in some cultures, the idea of comparing something to body parts may be seen as distasteful.

"Cat got your tongue?" - This expression means to ask someone why they are not speaking or responding, but this one never works either for obvious reasons.

"Let the cat out of the bag" - This expression means to reveal a secret, but the idea of a cat being in a bag may not make sense or may be seen as cruel for non English speakers.

Common mistakes that new software companies make and how to avoid them

Starting a new software product can be a daunting task, especially if you are new to the world startups and software. While every new business journey is unique, there are some common mistakes that many founders make. After helping companies big and small - from Fortun500 beasts to one person startups, we think we’ve seen it all! In this blog today, we will discuss the some of common mistakes that we see over and over and also give some tips on how to avoid them.

Not knowing your customer

One of the biggest mistakes that software product leadership make is not knowing their customer. Notice I’ve kept the term very generic, “software product leadership”, and that’s because this mistake is made by startup founders as well as product teams in well established software outfits! It is important to have a clear understanding of who your target customer is and what their pain points are. This will help you develop a product or service that addresses their needs and provides value. Take the time to conduct market research and talk to potential customers to gather feedback and insights. Remember that the software you are making is not for you (well it may well be, but you are probably not its only user). So make sure your biases and fascinations don’t guide the software requirements. Find out out the real customers, find out their actual needs - their needs may not be at all like yours. We recently posted a detailed strategy of finding what features you should plan on your software - worth reading that too if you are considering this point. Also worth a read is another recent post about finding customers for a software product.

Not having transparent conversations with your co-founders

Co-founder relationships are critical to the success of any startup or a software product launch. It is important to have open and transparent conversations about roles, responsibilities, and goals. Without clear communication, resentment can build up, and the relationship can deteriorate. Make sure to have well-organized conversations that are designed to share how you feel about the current situation of the company, how it's organized, and who is responsible for what.

Not launching

Many startups are afraid to launch because they think they need to be fully ready before they can get in the press or be on popular blogs. However, launching is not as significant an event to your users as it is to you. If you think about it, how many famous platform do you remember being launched? We only find out about a new product once it starts getting traction - think Facebook, think LinkedIn and think if you ever heard them at launch time… most likely not! It is important to move up the launch as soon as possible to get your product in front of customers. This will help you validate whether it solves their problem and give you the feedback you need to improve. Remember the minimum viable product (MVP) way of doing things. With an MVP you move to a faster launch and a faster way to more feedback. A long time back we posted on our blog an article about how every software company should launch with an MVP and it’s one our most read articles.

Not using analytics

Measuring what your users do when they come to your site is critical to improving your product. It is important to track your website analytics and user behavior to understand what is being used and what is not. This will help you make data-driven decisions and prioritize features that are important to your customers.

Not prioritizing the actual product!

Startups often prioritize sizzle over the actual steak! I mean they make more fuss about various things around the product than the actual product itself, such as hiring, press, and conferences, over getting the product out there and talking to users. However, the actual work of startups is pushing product, getting it in the users' hands, and seeing if they like it. Prioritize getting your product in front of your customers, gathering feedback, and iterating on it to make improvements.

These are some of the most common mistakes that we see many companies make. While it is possible to be successful even if you make these mistakes, it is important to minimize them as much as possible to improve your odds of success. Good luck!

Top 5 challenges of building an effective software team

1. Finding the right people for your team

This is without doubt the hardest challenge. Finding skilled software professionals is hard, but find the people who work can work together is even harder. Although this is the hardest there is no way around it. The success of any software project depends on one factor - how good the team behind it is. We know this from our experience in working with 100s of software projects over the past 18 years, but research and data in this area also shows this fact. In their comprehensive study of software project failures published in Software Development Failures: Anatomy of Abandoned Projects Ewusi-Mensah, K. showed that factors related team composition and team dynamics comes up very high in absolutely every single software project that has failed in their group. Similar connection with team related factors are found in other studies too. A good summary can be found in a paper titled core factors of software project success.

Table comparing softwre project failure causes from paper: https://www.researchgate.net/publication/330290988_Core_Factors_for_Software_Projects_Success

You need to focus both on the skills of the individual resources and the fit of the resource between each other to find the right team. A mix of skills is very important, so as you are composing the team work on looking at individual potential candidates and map out their skills - both technical and soft skills. Find a balance where you have various technical skills spread out along with the soft skills. An example could be that for a web development project in .NET you should look for people with core .NET programming skills but also add people with database, javascript, UI/UX skills. And again on the soft skills front you should have some members of the team who are good communicators, some who are good mentors and some who can run a debate well.

2. Getting your software developers to communicate effectively

Once you have the right team your next big challenge is to setup a system, a workflow and a culture where commutations happen in a flexible and free form way. You want multiple channels of formal and informal discussions. You’d want formal structures like team meetings and brainstorming sessions coupled with informal channels like a talk in front of the water cooler. At Kaz a great place for informal communications is the team’s own break space - we call them ip - interaction points. Sometimes it’s a veranda with some chairs where team members take their tea/cigarette break and has a chance to discuss something that’s bugging them (sometimes its about the the project too!).

It’s vital that your team should communicate effectively. Many a great software team has produced failure by the fact that the management made it too difficult to communicate - maybe with too many formal meetings or too few.

It’s hard to suggest a winning formula that works for every team as every team is different, every project is different. And add to that mix the WFH and remote work you have an even more complex problem. Work with your team to make sure there is effective discussions happening. Check back regularly on the health of that communications.

3. Developing a process that works for everyone on the team

Once you have the #1 and #2 sorted out you are half way there. The rest is pretty standard operations setup but it’s still super important to get things right. The top thing on the operations part is setting up the workflow.

A software development workflow involves all the nitty gritty steps of getting the software requirements, specifications, planning, distribution of work and then getting that work done in phases. The catchall word for anything related to software development workflow these days seems to be “agile”. But saying “agile” is not good enough. Setting up a workflow - if it’s driven by the concepts of the agile methodology that’s great - is important. Again, the thing to remember is that every team is different, every project is different and every company is different. The “agile” that’s right for you might be different from the “agile” of a different team or company. Plan the workflow that fits with your circumstances. For example, if you working on startup’s proof of concept project and entire future of the startup depends on showing this POC fast to it’s investors so that they can get some funding to actually build the thing - having a complex process for creating and tracking tasks that has to be reviewed at multiple steps is going to be a disaster. You’d want a process that is fast, relies mostly on verbal communications and commitments and almost no red tape. The opposite would be true if you’re working on upgrading an existing ERP that a large number of customers relies on it’s day to day work and single breakdown can lead to a lot of trouble fore everyone.

4. Creating an environment where every member of the team feels valued, respected, and included

In the mode of efficiency and engineering that software projects tend to push us we forge that at the end a team is a just another group of people. They are no different than other groups of people in our daily lives - each with their own needs and desires. It’s vitally important that in the hectic pressure of the the project, the need to find great resources and in creating efficient workflows we don’t forget the fact that the team members individually and the team collectively needs to feel valued and respected.

The worst offender in this space is the high handedness management teams sometimes use to operate with development teams. They somehow feel that they need to command and control the teams - which just doesn’t work in the creative and intellectual space that software development projects work in. It’s important to we aware of this danger of detachment from reality and keep honest reviews on the company’s attitudes and processes to make sure that the team feels happy and motivated. Remember that in software a demotivated team is directly equal to a failed software - there is no mid point in this equation.

5. Balancing what's best for your company with what's best for the team

The last point is a delicate one. You might have the best resources, you might have a streamlined process with a healthy team motivation in place but you are still operating within a business. A business has priorities and typically it’s about money and short term goals. These priorities will always clash with your team’s health. Short term goals will mean over working the team, it might mean a burnt out team and it also might mean that team members pushed around various things in their project (something that developers hate). It’s not an answer to say that I don’t care about the goals of the company - as those very same goals make the ends meet and get the funds for everyone to live. And on the reverse it’s also not an answer to say that we’ll sacrifice the good of the team to make the goals of the company work. There has to be a balance somewhere. The team will have to compromise on certain things (e.g. maybe a special impossible deadline for funding) and the company will have to compromise on others. If you get the balance right you’ll have a wonderfully efficient team in place.

OK, lots of heavy stuff. Let me finish off with a stolen Dilbert :)

Sourcing your software talents from around the world

A brave new world has arrived. A world where the age old concepts of work, workplace, office, meetings and all things related to work has changed forever. And I’m not talking just about WFH. Sure, work from home (WFH) or as some people prefer to call it “remote work” has become accepted, in some cases become permanent, but I’m talking about a much bigger thing than the acceptance of working from home. I’m talking about a paradigm shift in our way of doing work. The past two years (almost!) has forced this shift in us - in most case without us fully knowing. The paradigm shift is the idea that - work can be decomposed, spread out to talents who can do them anywhere in the world and re-composed. Any work can be split up into little blocks, and those blocks can be done by anyone, anywhere in the world and then those blocks can be put together and made into a whole.

This new paradigm works wonderfully in software work. Software development was half way there anyway, with teams spread out, tools of work (like the source control, servers) in the cloud, etc. But the pandemic just pushed the model further - specially to the skeptics (read management!). The formula for the new world in software projects is:

Step 1: Find talents anywhere in the world

You don’t wait for the talents in your neighborhood anymore. All you need to do is decide what skills you need to get the job done and then find a source for the talent online. There are freelancers and consultants available on sites like Upwork or Toptal or if you are looking for a more professional team that can take care of the whole blocks of things for you (and if need be the whole project) then you find a reputable company on a site like Clutch or you can rely on software company like us (shameless plug, but not too bad an advice).

Software is the same everywhere in the world - that’s the beauty of standardized syntaxes and compilers. So why wait? Treat the entire world’s software skills as yours to pick from - exactly like shopping from Amazon instead of your corner store!

Step 2: Bring them under your project’s virtual roof for a set period of time

The set period of time is the beauty of this new world. No longer are you tied to huge burn rates and HR overheads. You slot in the right skills at the right time and slot them out when their job is needed. If you can get the right partners and the right tools in place then it’s like magic - suddenly you have access to hundreds (if not thousands) of resources whenever you need them. It’s like being Microsoft on a puny budget!

Step 3: Get your software made!

Of course! This part is the same as before, well mostly. You will probably need to do a bit of composition with the blocks - that is bring the outputs together for the final software. In all likelihood you’ll probably do it the old style way but this too can be done in the new way of doing things and just relying on the resource cloud that you have in your hands!

The brave new world is great. The world is your oyster now. Happy software development.

Psst… if you want a great software team to help you make your software give us a shout at info@kaz.com.bd or just use box below to send us a message :)

Why do software projects fail and how to save them

A recent post about making software project plans that work started a thread of conversation with a fellow software guy about how true it is that software projects are prone to fail and we should just accept that fact and plan around that. His point was that we should actually take a more positive attitude that software projects work out at the end and work from that positive space managing the risks. He does have a point, any work starting out with a negative thought actually leads to bad things - your thoughts are a thing as Napoleon Hill says in a book about wealth creation. And it’s a good question to ask - what is a better approach for software projects - assume failure and plan to manage it or assume success and avoid traps?

Facts & Data

Let’s look at the facts again. Research after research shows that software projects fail most of the time. A great source of software project health in general are the CHAOS reports published by the Standish Group. The CHAOS Reports have been published every year since 1994 and are great indicators of the state of the software space.  The 2015 report studied more than 50,000 projects around the world, ranging from small few man week software projects to huge thousand man year IT projects and system implementations.  The results show clearly the trend that software projects are failure prone. Take the summary pie charts in the report (shown below). The red is ominously present in all the three aspects that were judged - budget overflows, timely delivery and feature achievement. I agree that the green is also strong (note the error on the first pie though, where the colors are flipped!) but shouldn’t you the red to be much smaller on all those pies? With such large amounts of money spent and with companies betting their existence these days on their IT systems having that high percentage of red is not a good sign.

And don’t think this is a recent trend. Actually things have been getting better over the years. Software projects have always failed but the rate of failure is reducing (at least according to these guys). The stats show the success percentages are going up over the years, so that’s definitely good!

Why do they fail? And, how to save them?

This is obviously the million dollar question (I guess a billions of dollar question in this case). Every software project is different, be it with the requirements, the nature of the product, the nature of the customer and the nature and composition of the team that worked on it. So it’s impossible to generalized. But overall some common risks are seen in all software projects that can if left unmanaged lead to be one of the factors of failure. Note that I said “one of the factors” as most software projects fail not because of one single cause but a whole bunch of them, each stacked on the other. So instead of talking about generalized causes of failure, let me just claim that most software projects have the following risks that should be managed. It would not gurantee the success of the project but it would certainly make the project safer.

Bad project planning

In our experience, bad project planning is the biggest cause of software development failure. This is one area of engineering where project planning makes it or breaks it. You can have the best developers in the world, unlimited budget, time, documentation yet if you don’t plan things right, if you don’t plan things realistically you’ll just burn that team, eat up that money and time and end up with a bad software or no software. To take a recent software project that failed despite having everything ($1.7 billion budget, 1K+ strong team, etc.) is the US’ healthcare.gov platform. It was way over budget (original budgeting was $93.7 million!), severely delayed and very buggy even when delivered. Problems started as soon as it was somehow launched. Although it was known from day 1 in the planning that there will be huge demand, the huge hit caused the site to go down within the first 2 hours. While website user hit initially cited as the main cause (inexcusable as this was one of the given parameters) other problems showed up because the UI was not complete or confusing. Issues such as drop down menus not being complete and insurance companies information data not being correct or complete was a common problem. By some estimates, only 1% of people managed to successfully use the site on the first week. On October 20, 2013, President Barack Obama remarked, "There's no sugar coating: the website has been too slow, people have been getting stuck during the application process and I think it's fair to say that nobody's more frustrated by that than I am." It was all down to the poor project planning.

Work on that project plan. Read our recent post about project plans that work. And most importantly work with skilled project planners who has experience to understand the problems of a software project.

Lack of communications or excess of communications

Software is always a collaborative exercise. You need open channels of communications that are fast and reaches a resolutions quickly. The the quick resolution is also super important that is whey the excess of communication is something to worry about. You have to monitor that “analysis paralysis” doesn’t creep in just because there is a lot of communications possible.

Too many targets & unrealistic goals

Often the only things that pushes a efficient and streamlined software project towards disaster is the multiplicity of goals. A team can only do one thing at a time with a good quality. If you try to push them to do too many things even with the best of planning they will burn out over time and reach a point where it is only the team’s speed that hinders the success of the project.

Many great companies fail to understand this - they push their wonderful software teams to create great software one after another - pushing new features in, pushing new versions and upgrades in - at one point the team just breaks down. No matter how good your plans are or how good your communications channels are a burnt out team will always lead to failure.

Too large a team and too large a project!

Software project size and the team that works on them have an optimal size. Beyond that optimal size things don’t work too well. Communication becomes too noisy, mistakes start happening, people tend to lose focus and the wonder project plan starts to break down. Over and over research has shown that larger projects fail more than smaller ones. Here’s a table from that 2015 report:

If you have a large project or a large team - break it down to smaller projects with smaller teams that interact at set points to build the large project by parts. That is the only safe way of doing things - we know it from experience and data proves it over and over. I’ll finish with this quote from the report … says it all.

“... that size was the single most important factor in
the resolution of project outcome ... It is clear that the larger the project, the less valuable the return rate. In many cases larger projects never return
value to an organization. The faster the projects go into production the quicker the payback starts to accumulate. ”

— CHAOS Report 2015

Top 10 Questions you must ask your software vendor

Do you have any questions for your software vendor? You should. The standard stuff like what is the size of the vendor’s team, what are their skills, how long have they been around are usually available easily at the vendor’s website, their brochure or they are more than will to just give you that information. What is more difficult to know yet vitally important for you are the answers to the not so easy questions.

Here’s our list of top 10 questions that must be asked before any software development relationship is set up with a new vendor. There are obviously a lot more, but we feel that these 10 must be asked no matter what and the answers to these should be discussed internally with your team to see if you see a good fit, to see if you agree or accept those answers or not.

1. What are the company's values and goals?

You might think this isn’t all that important for you as a customer, or it’s just some marketing blurb that you can by pass - but you’d be wrong. A software development project isn’t like many other projects around, it’s not like a simple product you buy and then you can pretty much live on your own. A software development project means a sustained relationship for a period of time (usually pretty long - remember it’s just not the development time, but all the maintenance, updates, upgrades and fixes of a software’s typical lifetime) . So what your vendor’s values are, how they see the business, what their goals are - all these matter because you’ll need to agree with them, be comfortable with them and at the very least accept them. For example if the vendor feels that their real goal is to become a giant in 5 years, then you need to think if that fits with your goal of working with a stable and small team.

A picture from 17 years ago at our old office where we had those beautiful mosaic patterns you don’t see anymore.

Sometimes alignment of values are a very good sign that things will work out in the longer term. I remember a long time back I was showing a prospective customer our old office space that had these beautiful, intricate mosaics and I mentioned that we love these patterns and we take extra care not to destroy them somehow. She just absolutely loved it and said her company was a 3rd generation owner company that valued traditions - and we knew we had a good alignment. And indeed over time that has proven to be so true, having worked with them for a long time and launching several of their flagship products.

2. What happens when you fail to deliver something?

This is the hard question that all software vendor will try their best to avoid. But you absolutely have to ask. Things do go wrong in software (actually all the time, some studies have shown that 78% of software projects fail, a recent post of ours tries to find a way software project plans can be done to avoid failure). So asking how the vendor will manage that risk is essential. If the answer to that sounds vague or if they say the impossible - “we don’t fail” then think hard if this is a good fit, dig in deeper to see how reliable that partner is. Every software project should have a disaster recovery plan - simple. If a vendor doesn’t have one or isn’t planning one then there is something wrong with that vendor.

What you should be looking for is a realistic yet confident approach towards delivery failures. There should be a risk management plan - a risk containment and mitigation approach. They should be ready to act when a failure happens, and draw on the experience and knowledge from past projects and from the team to minimize the impact to the project.

3. What happens if a team member leaves suddenly?

Software is very much a team effort where every team member is essential. Over time a team member becomes an expert of the project and its requirements. Developers grow the essential familiarity with the codebase, the features, the decisions and the compromises that make a software project work smoothly and efficiently. So when a team member leaves it puts a huge dampening effect on the overall project and the vendor must have a good plan to first manage the team so that doesn’t happen and then manage things when it does happen.

More on this theme on question 8 below and there is a reason to separate them out and ask them a bit spaced apart. You want to revisit this topic to see if the answers fit well.

4. Can you provide case studies of customers who have been successful with your software?

5. Can I speak with a client who is using your product now to get feedback on their experience?

6. How many projects like mine has your company completed in the past year?

This is pretty standard stuff - but sometimes these case studies are not shared publicly. Maybe an NDA prevents the sharing or there are some other reason why they don’t want to put these in their marketing material. So it’s essential to ask and then review these case studies. These are projects that has worked out so you should get a feel of your own project fitting in those - see if you can imagine your project being one of the case studies in the future. Ask questions that are not answered or issues that are not clear in the case studies.

7. What's the best way to reach you during and outside normal business hours?

8. Who will be my point of contact throughout the project?

Standard questions but you’d be surprised how many customers don’t ask this. You should have a clear picture about what to expect when the project is running in terms of communications. All projects will have at least one point in its history where you are desperately looking for a quick answer to a question. It could be during an important demo that you are giving to your prospective customer, it could a bug you spotted that needs a fix right away. You need to know about the contact points and be absolutely sure before any vendor is accepted.

9. How do I know that I can trust you with my data?

Data security if everything in software and it’s important you ask this question right at the beginning. There must be a very clear procedure for data security at the vendor’s site. They must have a plan and a process that ensures that the plan works.

10. How long have your employees been with your company, and how many years of experience do they have in this industry ?

This is a revisit on the team stability question of question no 3. Vitally important question and a revisit is needed to see if the answer to this fits with the answer to the other.

Good luck with your vendor hunting!

How to motivate a remote team

Remote work is now the norm. This is one thing that the COVID has pushed us to and has proven that it works. Companies that never did remote work (including us at Kaz) are now fully functional and thriving with remote work. And remote work is here to stay as a work model - it’s very likely that every company in the world (including us) would keep some form of remote work in their process. Everything has a downside - and for remote work it’s the lack of the rest the team near you that starts having an effect. Over longer period of time motivation for work becomes a big stumbling block. And for manager and team leads it’s not an easy problem to solve. But we’ve found that it’s not an impossible problem either.

“77% of remote employees say they’re more productive when working from home”

— Survey by CoSo Cloud

You don't have to be next to someone's desk in order to feel the energy of a team that can work together and accomplish goals. As a manager, you can motivate and inspire your remote team just as well as you would if they were all sitting in your office.

Here are our top tips for motivating your team remotely.

1. Set clear expectations for your team

We are used to taking visual ques from all our interactions, these ques form much of our understanding in any conversation. A remote team misses a lot of these visual ques in an interaction over a zoom call or worse over an audio only call. So it's vitally important that common understanding of expectations is reached. We tell all our customers to set aside a slot at the end of every meeting to just go over the main points of the meeting and check that the both sides agree on what the expectations are.

2. Be transparent about what is happening

When your remote team feels out of the loop, they are less likely to want to engage. People are motivated by being informed about what is going on around them, so tell them! If they miss something, feel free to say "let me go over that thing" or "you should hear about a new development that is happening". This is especially true for software teams, as software development is typically a very collaborative effort and if the remote team feels that they are left out of decisions, changes in requirements etc. it will create a loss of motivation and just make the overall process of software development difficult.

3. Communicate regularly

The remote work experience will be a lot better if there are regular communication channels between the remote team and the office. Some ways to keep them in the loop is by having weekly meetings that are open to all members of the remote team, sending out emails with important updates on new features or scheduled changes, etc. Asking them regularly how they are doing, where they are on particular tasks or deliveries.

There are many other ways you can motivate your remote team. Some of them are time off or bonuses, but at the end it is about working with people who enjoy what they do - And if they are happy to work for you, you will get an effort that goes beyond the job requirements.

For small companies this might seem like a lot of overhead, but it is vitally important for the longer term.

“2020 has seen a 9% increase in Google search interest related to “team-building””

— www.thinkwithgoogle.com

How to make a software project plan that actually works

Making a project plan for software development is one thing, but making it work is another. You've probably seen lots of software project plans in your day. They all look the same with their pretty Gantt charts and lovely blue annotations, don't they? Yet, do you know the failure rate of these pretty Gantt charts? That number is an unbelievable 78% according to one study in 2009 (the same group found a failure of 84% in IT projects in 1994!). This humongous failure number keeps coming up in studies after studies, here’s one by another very respected group - McKinsey-Oxford study for IT projects

Given these huge failure numbers we have to accept the reality of difficulty of making a software project plan that works. Over the years we at Kaz Software have worked on numerous software projects, for hundreds of companies around the world and we know from first hand experience how difficult this is. There are hundreds of variables that you should be thinking of when making a reliable project plan - from obvious ones like requirements, business priorities, resource availability to unexpected ones like language barriers, paperwork, compliance issue, etc. On today’s post I’d like to share some of the things we have learnt about making a better project plan - not perfect, maybe perfection isn’t possible, but a better one at least!

Decide on a project timeline and set deadlines

The first step is to decide how long your project will take. One month, three months, six months? Or maybe you can't put an exact number on it because you aren't yet sure what the project entails. That's fine too - just be as accurate as you can. The point is to be realistic, to have all the information available at that point in time and make the best possible guesses based on that information. If you know the requirements will change frequently, set deadlines for each round of revisions. If you think your team members are bad at estimating their time, maybe give yourselves a longer timeframe. Set deadlines that are achievable but challenging. Don't be too optimistic or you'll end up disappointing yourself and everyone around you when things don't go as planned.

Create a list of tasks with a democratic estimation

This is where you break down the requirements into smaller areas, features and then eventually tasks. Make sure you about break large, vague tasks into smaller tasks with deadlines that are based on the time estimates. Breaking down the larger tasks into smaller tasks are relatively easy, especially if you have experienced resources in your team. Where it gets extremely hard is the time estimation of tasks. Most developers will either overestimate or underestimate time cost for a task. This is just a fact of life. Our solution has always been to use democracy to find the time cost number - effectively asking all members of the team to discuss and come up with a time estimate rather than relying on a single person (the developer who is likely to do the task). This may sound counter productive, as the task will be done by a single developer at the end of the day - but somehow the democratization of this process gives much better result.

“Realistic schedules are the key to creating good software. It forces you to do the best features first and allows you to make the right decisions about what to build. Which makes your product better, your boss happier, delights your customers, and—best of all—lets you go home at five o’clock.”

— Joel Spolsky

On this point I’d like to note another very effective way of getting time estimates - which is to look at historical success and failure rates of estimates per developer and based on that decide if the developer typically over or under estimates and then add or subtract based on that data. This idea was very effectively put into use in Joel’s FogBugz product - and he called it evidence based scheduling. You do need a platform like FogBugz to make this happen, and even then you need to have enough historical data with the same developers to make it really work.

Write down the resources needed for each task

This is where you list who's expertise is required to complete each task and what kind of equipment will be used. If the skills required for a task is not available in your team, plan for it - how you will fill up the gap, what steps you'll need to take to have that skill available at the right time. Some of those steps may be tasks themselves that you have to add to your project plan.

Set up milestones that you'll need to meet

Milestones let you know how much progress you've made and if everything is on track with your timeline. You can set up intermediate deadlines as well if you're not afraid of breaking your work into smaller chunks. If you have a long term project, it may be better to set up milestones at the beginning so that you'll know how much you can do every week or every month.

Make sure your plan is achievable by breaking it into small enough chunks so that you can achieve them one by one. Divide and conquer is the the only way to solve the complex problems in a software project. If you decide to take on something big, it can quickly become overwhelming. Try breaking your project into smaller pieces and figure out how long each one should take.

Stick with it!

Don't give up when things get tough! You're almost there! This is the most important tip of them all. If you have failures, delays, setbacks just know that that is a fact of life for all software projects. You just have to have the patience to stay with your plan, make changes as needed to adapt to the delays and move things forward. Software projects never go as planned, and one of the greatest sign of a good plan is that it has the ability to absorb the changes as they happen. And the one most important skill of a software leader is the the ability to stick with the plan.

Remember that a software project is a process, and it can be thought of as a linear progression from one phase to the next. Plan out how you will go from start to finish with milestones in between. Use your resources effectively by having the right people on the job for specific tasks, making sure you have access to special equipment or resources.

Let’s break these horrible failure stats. Good luck!

Making you software dreams come true

Now is the time

It's never been easier than now to actually develop and release your first piece of software. You can do it in spare time after work or on the weekends so you don't have to wait and delay it anymore. The technology exists to help you move things faster. The only thing that is holding you back is your fear.

 You are not alone in this. There are many people with similar fears - some of them are even afraid to post their ideas on the web because they think someone will steal it. But this just doesn’t make sense, we know first hand how hard it really is to make something good and useful so the huge moat that exists from idea to a real usable software is huge. Ideas are easy, it's the execution that is super difficult. I will argue in this post that now is the time to start - you can start with something and end up with a very different product and a different company. Remember you can always run a rebranding of the company once you know exactly what works. Here’s how you should start.

Take the first step

We all have dreams about making something useful, something that solves a pain, something that makes our life that much easier. That is exactly how all the software platforms around us started. It's very easy to forget that when you are in the middle of the whole thing. But it only takes a bit of research to uncover all the stories behind today's giants. And these people weren't billionaires sitting on their money before they made their products, they were just like us, with big dreams and nothing to lose. Sure there was some hiccups, maybe huge ones, but every little mistake is just another signal for you to change your idea so that it fits with what the market needs.

Start deciding now what is it that you want to make and start doing some research about what the market needs. This way you will make sure you are not wasting your time and energy on something that has already been done or that can't be done properly because there is no demand for it. Of course the last point raises the question: How do we find new ideas? How do we know that the software I'm planning will be something that everyone wants?

What do people really want?

Sometimes it is easier to find a gap in the market. This simply means that you research what your competitors have and try to analyze what they are missing or not doing properly so that you can offer the same product with more advantages. For example, there were a lot of applications for office tasks but no one offered a solution for lunch at the office easily! And that's the niche that all the food delivery platforms filled in. Food delivery disruptors like just eat or uber eats are just ideas that came by finding the gaps in our everyday life's workflows. Take this from the wikipedia article about one of the oldest food delivery apps: :Takeaway.com was created by Jitse Groen in 2000 after he had a difficult time ordering food online from local restaurants. Initially, Groen wanted to deliver all kinds of consumer goods; however, he noticed that food deliveries had the most demand, and decided to make this the company's primary focus. This is a common story for most successful apps.

Another way is to think of something that you just hate with a passion and then come up with a solution. If you have an idea, don't wait for it to be perfect - put in the time and effort right now! Chances are likely that there are many others who share this dissatisfaction with what currently exists so your product will probably find some fans. That's all you need to keep the ball rolling - some early adopters. They will give you the ideas of what else is needed to make it even more useful. What features people will pay for, what they lack in the market. Starting from a small set features leads you to take the baby steps that lead to software that people really want. Take any successful software as an example, look up their history and you'll find that they all started with a very very small set of features and they changed, updated and upgraded all the way. Do you remember how MS Word 1.0 was? It was a disaster, a buggy software that had much less features than the leader in the field then Word Star or Word Perfect. But what MS Word did was solve the pain of remembering formatting codes and use the wsywig paradigm to make users' life easy. It wasn't perfect, but it was a start.

Software is difficult. It requires dedication, creativity and endurance to make it happen. You will have to conjure up the programming language that fits your needs, come up with features for your software, make sure everything works across devices, platforms and operating systems. But if you are now finally ready to face all these challenges - welcome!

How to evaluate software development company performance

Do you find that your software development company is taking too long to deliver a project? Do they lack creativity and innovation? Would you like a partner who can provide accountability and transparency in their work? If so, read on.

As a custom software development company that have worked with hundreds of clients all over the world we have come across all kinds of situations where multiple parties are involved in creating a software platform. The performance of each party is crucial for the overall pace and success of the software project. And we have advised our customers about how to monitor and assess performances of their vendors - including ourselves! In today’s post I will summarize some of the biggest tips we have for our customers to assess the performance of a software developer.

The basics

In order to evaluate the performance of a software development company, there are four criteria worth considering:

speed, price, quality & service

Here's how these factors stack up for one of our clients:

-Speed: Slow delivery times lead to lost revenue as well as frustrated customers. Our client has already seen an average 30% increase in productivity from the new vendor we partnered with them on this project.

-Price: You get what you pay for! The old adage applies here, however there is a big mitigating factor here - location. If you are using a vendor at a relatively lower cost location such as ourselves based in Bangladesh you have the opportunity to find a price that is lower without compromising on the quality.

-Quality: This is the the most important one. In the world of software the only thing that really matters is quality. And you could compromise on pretty much all the other factors but not on the quality.

-Service: How’s the requirement analysis, the communications during the build, the delivery, the promises kept and the promises broken? All of these go towards the service metric.

The performance measurement matrix

The performance measurement is not a linear operation. That is to say it is not a single number you are looking at. For example a company that is great at quality might be really poor at speed. Does that mean it’s a badly performing vendor? The only sane way of getting a full view of the performance is to create a matrix that goes over the issues at stake and measures each one of them against the four basic dimensions of performance mentioned above.

One thing to note before I jump into this: there are hundreds of “scientific” way of measuring performance of a software development vendor. This is a topic that is favourite with efficiency specialists, university computer engineering departments and large multinationals with huge investments in IT. If you really want to get to know some of the research work that is done in this space a great starting point is the highly academic yet useful book generalized towards engineering organization performance: Performance Measurement and Management for Engineers or if you prefer a google search will lead you to a pages and pages of approaches towards measurements. What you’ll soon learn is that there is no standardized foolproof way to do this. At the end you end up with a lot of hand wavy metrics. All the big names in software has said something or other about the futility of measuring performance in software projects! Here’s one I like a lot:

“So while I see the value of measuring individual performance in research settings, I think its difficult to find cases in which the effort is justified on real projects.”

— Steve McConnell

OK, now that I’ve got that out of the way, let me go over what we suggest. Our approach is pragmatic. We accept that no measurement scheme will be perfect, so all we can do is layout some basic information in a way that’s easier to visualize and let project owner do their own assessment based on that. So that leads us to the matrix I was referring to.

The columns in the matrix are the four basics - speed, price, quality & service and on the rows are the questions or issues that matter to the project or to a particular company. In this super simple method we take away the pain of running elaborate surveys, questionnaires, software line of code analysis etc. that some approaches use and use a very intuitive way of quickly getting to some feelings about the overall performance. Note that the number of rows, that is the issues, actually vary project to project, company to company. And that makes perfect sense, what matters to one project may not be an issue at all to worry about in another.

Here’s a sample matrix that we did for one of our customers recently. They had a total of 28 issues that they tracked with this, beyond the ones shows in the screenshot the rest were specific the product features, stuff like “All screens should update with animation”, etc. These made sense for this particular customer as they thought this was essential for the assessment of performance, but for many other companies such a granular level or such a narrow scope for the assessment wouldn’t make sense. That is the beauty of a simple matrix approach such as this one - it is flexible and can be adapted to the need of a specific project/customer/vendor situation.

When it comes to evaluating software development company performance, there are a number of factors that can help you determine if the vendor is working in your best interest. I’ve outlined our suggested way that seems to work very well for software projects. You can use this at regular intervals (we suggest every 6 months) to check the performance and detect signs of change. The change in scores from previous ones give you the signs of a change in performance - for the better or for the worse. Do any of these signs apply to your current vendor? If need help give us a shout at info@kaz.com.bd to learn how our team might be able to help you.

Making your software: Step 5 - Select a development partner

Priya, our fictional software entrepreneur from the previous chapters on this series has a dream to make “Designly” a software platform for interior designs. She has followed our suggestions on writing down her features in the specific format that software developers love as step 1 in her journey to make her software. She has then gone through the methodical approach of finding possible software developers using a simple yet effective process using the method laid out in step 2 - find software developer She has then followed through to step 3 - to get ballpark estimates that gave her the information to budget and create a financial plan in step 4 - budgets and funding. Now she has the all the groundwork done with a good plan to move forward. Now is the time to roll up the sleeves and get into action - the actual software development of the product. And the first step in the action is to select the software development company that will do the job for her. From her previous steps she has nice and short list of good vendors, she just needs to make up her mind in this step to pin down the one she wants.

Part of the selection process is to setup the contracts. The actual legal contract is important, but at the end secondary - since no legal write up can replace a good working relationship. It’s extremely important to setup an operating process - decide how the project will move forward, how you’ll see the results and give feedback, the timeline, etc. The non-disclosure agreement (NDA) is Priya’s protection for the idea about the product as the software company will require her to go over the details of her idea before they can give a final costing they can commit to. There are variations to this plan, but this is typically the path most companies take.

The NDA

The NDA, short for non-disclosure agreement is Priay’s protection of her idea. For the software company to brainstorm and finalize her business idea to fit with a practical software within the limits of budgeting, they need to know in detail about Priya’s idea. The NDA provides protection to Priya in the case where the vendor doesn’t just steal her idea and builds it themselves. In the software world typically ideas are the common thing, implementation is the hard part, but still the NDA provides a much needed peace of mind for the two parties to discuss without fear.

A good NDA will help both sides. So there are typically time limits to the non-disclosure, also well defined definitions for scope about information. It’s obviously vitally important for Priya to protect her business secret and make sure that the vendor does not go away and make it product like hers. On the other hand a typical software vendor will be working with a multitude of customers, some within the same business area as Priya. So the vendor would also need protection from an over restrictive NDA that exposes them risk of breach even though the situation may be just a case of working on similar ideas for different clients. This balance of protecting both sides can only be achieved with scope and clear definitions of what constitutes a secret and what doesn’t.

For most contracts it’s best to use the help of a legal expert. However, NDAs are so standardized these days that Priya can get by using a template from the internet. Here’s one that we like: Free software NDA template but a google search will land Priya many other good ones. Note how the NDA has very clear definitions of information, exclusions and time periods.

Work plan

The next big thing in this phase is come up with a workplan - how the software developer will work with Priya to create the product. The workplan doesn’t have to be very detailed like a project plan, that will come in later when the software mockups are done and the software developer has enough information to create a milestone based project plan. The workplan is more a discussion and an agreement (maybe a verbal one) about how the next few steps will be done and then how the software development itself will be done.

Every software development company has it’s own way of doing things. There are some broad similarities, but the actual working plan is very specific to a software company. So it’s important to clarify that plan so that Priya knows what to expect and also the vendor gets to know about any concerns or timeline pressure that Priya might have. And it’s a good idea to do it at this early stage so that an red flags are spotted early and fixed (hopefully) before any side has made any significant investment in time and money.

A typical work plan (something we at Kaz follow for example) is:

1. Create team for project with clearly identified responsibilities and contact channels (say skype/phone/email/…)

2. Do a series of meetings go over requirements and create wireframes for the main features of the product.

3. Once the wireframes are finalized, create colored mockups to design the exact look of the final software.

4. Create a detailed project plan with timeline and delivery milestones.

5. Finalize the pricing and create a software development contract (unless this was done before).

6. Setup of shared issue tracker.

7. Setup of shared staging environment where client can see product on every build (usually daily).

8. Weekly (if not daily) status meetings and early feedback sessions.

9. Development and delivery at milestones.

10. Feedback sessions at delivery milestones.

11. Demonstration of key delivery of the product with larger groups on both sides.

12. Pilot phasing/Quality assurance sessions/UAT/etc.

13. Deployment on live infrastructure.

14. Support for live system.

15. etc.

End of step 5, Priya will have a software developer finalized and have a clear idea about the process that will get her the software application she wants to build. Now comes the fun and exciting part of actually building the software! It may feel like Priya is taking a lot of time to get to this stage, but remember that selecting the right partner, having the budget planning and having a realistic idea about the process is the only way to successful software product. Any shortcuts here could prove to be extremely costly down the line with time, effort and money spent on something that is not the product. So it is vitally important to go through the motions and get to this stage with confidence.

Making your software: Step 4 - Budgets and funds

Priya, our fictional software entrepreneur from the previous chapters on this series has a dream to make “Designly” a software platform for interior designs. She has followed our suggestions on writing down her features in the specific format that software developers love as step 1 in her journey to make her software. In step 2 she went over strategies to find a software developer company who will turn her dream into reality. Then she gets good ball park estimates for making the software in step 3. Now that she has some numbers she can work on her next challenge of budgeting and financial planning for the software development.

Software development can be expensive, so a proper budgeting and financial planning is essential to make your software and launch it successfully.

Phases of software launch

There are several distinct phases in getting a software product to the market. These phases actually go way beyond the obvious software development and sometimes the founders don’t really realize all the steps and runs into difficulties with finances when that step happens. Here are some of the phases and what a founder should expect from a budgeting and finance point of view on such phases.

Design and planning

Every software product has a significant design and planning phase. If you cut this phase short you end up a poorly designed software that is hard to use or a software that took a lot more time and money to build because the developers just didn’t have enough guidance on what to make. So it’s essential to invest on the design phase. If money is tight, as it is on most startups, this phase can be less elaborate than what textbooks suggest about design and planning of software but it still needs to have some basic things done. The top focus should be a set of “mockups” of the software interfaces. These are pictures of the software screens as the user goes over common or most used features. If money is seriously short, these mockups can be just black & white rough sketches called wireframes, but that’s the bare minimum that must be done.

Typically this phase will require 10 - 15% of your total budget for the software.

Development of the MVP

This phase is the actual software building phase. MVP stands for minimum viable product and we’ll go over the concept of MVP in a separate post. But basic idea is simple: find out what is the minimum set of features that will sell the software and make that first and launch with it. Here’s good video about MVP..

Typically as founder should plan for 40 - 50% of her total initial budget for the MVP.

Launch and marketing

The launch of the product by itself is time consuming and can come with unexpected costs. The developers may request for server certificates, special cloud setups, software licenses that a founder may not have budgeted for. On top of that the launch process itself takes developer time which adds to the costs.

The marketing is obviously a huge area to think about when you are launching a product. Nothing sells without proper marketing.

Typically launch and marketing should be around 20-30% of total initial budgeting, but note that this is one area where it’s very product specific. If a software is planned to be something based on a huge number of users then marketing itself can take up more than half of the all the money spent in a project.

Releasing the updates

The biggest mistake that founders make is not factoring in the costs of making changes to the software AFTER the launch. These changes are usually the make or break between a software that people use and one that goes into the software graveyard. After all, only after a launch does a founder really get to see what works and what doesn’t, what her users are using and what they are asking for. Based on these real data points a founder has to adapt the software, modify it or fix the bugs to quickly launch a new version (usually a series of new versions) that adapts to the need of the market. This process is iterative, it’s usually time and effort consuming and thus it’s expensive. Not budgeting for this phase means the software never had a chance to fight it out in the market. So it’s absolutely essential.

Typically a founder should budget at least 15-20% of her initial funds for this phase.

Maintenance

Maintenance is the phase of managing to keep the software live over time. This may involve bug fixes time to time, maintaining the servers, updating various components as new versions of the OS or other software is released or new security patches are put out. For mobile apps this means the continuous effort to keep up with the new versions of OS that Apple or Android guys are coming up with, each having the potential to break your software.

A founder should budget for at least 2 years of maintenance after launch in her initial planning. Very much a product specific thing, but typically over 2 years it would take up 15 - 20% of the overall costs.

Payment strategies

When the founder is planning for financials of a project there are certain strategies she can adopt for the funding and the payment to the developers. These are general tips, after all, as each project is different with it’s own sources of funding, own specific situations of payments. Here are two strategies that works well for startups.

Milestone based payments

Setting up a payment schedule with the developer based timed milestones is great for both sides. For the founder it gives certain dates where she needs to make the money available, it also gives are a quantifiable way of seeing what she is getting before she does the payments and of course more solid commitment from the developers about the dates. For the developers it’s a good way of splitting up a bigger software project and getting paid as they build it. It reduces their risk by not lumping everything up for a big payment at the end.

Phased development

The phased development strategy is where the founder just makes her final product over a set of phases. Each phase has it’s own launch, marketing and payment. This way the founder can get the product out in smaller steps, judge the market as she goes along and only commit to more payments if she sees the demand. For a developer too it’s is a good way of splitting a large project up and getting paid early. But note that if the phases are too small this might be impractical for the founder and the developer as the costs of starting and stopping the project in each phase can be a big overhead.

OK, that’s it for today on this series on getting your software made. I’ll be back soon on step 5 soon about finalizing a software partner to get software made.