Technology startups success determinants in Egypt

Technology startups success determinants in Egypt

Technology startups success determinants in Egypt

This blog is part of the study i recently published on my blog. you may download it from the following link.

As mentioned in the title, this blog targets the success and failure factors and determinants of technology startups in Egypt. Although, i see it is applicable to any developing country or in countries where you find bureaucracy and corruption.

The factors and determinants mentioned here are the factors we studied. some of them are major others are minors. Factors are defined from literature reviews and peers interviews.

Factors are defined into four groups:

  1. Factors related to the entrepreneur himself
  2. Factors related to the Ecosystem and its maturity
  3. Factors related to the market and its size and purchasing power
  4. Factors related to the government

How do we define success. Success in business usually defined in terms of profit, usually expressed as “increasing shareholders wealth”. In startups, and specially in a country such as Egypt, the definition could be more deeper.

Success is described by; the longer the entrepreneur can survive and prevent involuntary exit, the more successful he is.

Below are the definition of each factors studied, and in a coming blog, we will study the effect of each factor.

ُEntrepreneur Factors

Leadership Skills: entrepreneur motivational attitude to motivate the employees to achieve the company vision and strategic objectives and goals.
Focus Strategy: entrepreneur motivational attitude to achieve focusing on a few target markets who are distinct groups with specialized needs (Focus strategy rather than diversification strategy).
Entrepreneur Qualifications: the effect of education, general experience and industry experience on all the business aspects.
Interdisciplinary of the founding team: the founding team diversity in experiences, education, culture and even nationality.
Business Skills: entrepreneur skills for recognizing opportunities and the entrepreneur’s willingness to take risk  and their orientation to make money.
Soft Skills: The characters and capabilities of attitude and behavior instead of knowledge or technical ability, Innovation, ambition, optimism, flexibility and adaptability.
Ethical Behavior: Ethical entrepreneur is committed to achieve business success, without contradicting with personal ethics and values, his/her humanity and honesty are motives against unethical business temptation.
Networking and Social Skills: The strong relationships with potential customers, business partners and government bodies.
Luck: The force that causes things, especially good things, to happen to entrepreneur by chance and not as a result of his own efforts or abilities.

Ecosystem factors

Availability of Incubators, Accelerators and Advisors: Availability of entities that provide know-how for the new business entrepreneurs, such incubators act as business accelerators for the ICT startups, also they provide advisors and consultants in various fields like legal and marketing advisors.
Availability of Financing Agencies: availability of Venture Capitals or Angel donors who have intentions to provide fund for small and medium enterprises
Non-Governmental Organizations Support: The efforts done by NGOs aiming for social and economic change which eventually helps the private business sector especially SMEs
Availability of Business Partners: All partners that provide entrepreneur with important activities necessary for his success.

Market Factors

Egyptian Market Opportunity: The presence of business need in the market to develop new products and services which are not fully supplied in the Egyptian market.
Egyptian Market Risk: The sum factors that make working in Egyptian market is risky
Customers’ availability: The potential for the market current customers to purchase the product/service to generate profit.
Demographic Factors: Unemployment, poverty, high dependency ratio, and illiteracy rates.
Government Support Program Efficiency: The measure of how efficient the government support programs to provide financial, technical and non-technical support for ICT companies.

Business Environment

Governmental Regulations: The governmental laws, rules and policies that affect the ICT industry either directly or indirectly.
Corruption: The misuse or the abuse of public office for private gain.
Military Service: The compulsory service in Egypt for males, from 14 months to 36 months based on the age and education level.
Infrastructure: The basic physical and organizational structures and facilities (e.g. power supplies, buildings, roads,) needed for the operations of ICT enterprises.
Political and Economic instability: The tendency of a government to collapse.
Internet Services: The availability of different internet technologies  which are efficient with reasonable prices, required for ICT companies in Egypt.
Legal Form: How the business entity is formed as per the local commercial law In Egypt
Legal Environment: The power of law enforcement represented in laws’ entities, procedures and environment that protect rights and provide justice for ICT small business in Egypt.
Availability of Qualified Employees: The ability to headhunt qualified and talented employees.


Exploring Factors Determine success of Small ICT Enterprises in Egypt


For more than two months, I was working closely with my friend Dr.Ahmed Hussien on a thesis with the same title “Exploring Factors Determine success of Small ICT Enterprises in Egypt”.  If you are a follower of my blog, you may notice my passion of entrepreneurship and startup. I am very close to many startup communities worldwide (USA, EGYPT, KSA, Qatar, …. And more)

Chapter five in the study is the most important one. It includes results and recommendations. Recommendations included advises for Egyptian entrepreneurs, government, ITIDA, and the Egyptian startup eco-system. In addition, the end of chapter 4 includes full picture summary about each factor results, analysis, discussion and recommendations

The study has been done on several stages that included a review for startup community in many countries, interviews with startup owners, and experts from the eco-system.

In the few coming weeks, I will discuss each result separately on my blog. These discussions will be a base for future focused studies. We will depend on people comments and interactions as a base for these future studies, so please follow my blog to be able to see future studies and to interact with it

Download the study1426700201_folder_download

Lesson in a graph, Relation between product life cycle and Marketing message, Distribution, Price, and management style

Relation between product life cycle and Marketing message, Distribution, Price, and management style

Lesson in a graph: Classical 4P’s and its components

classical 4Ps

Software Project Management, The mission impossible, Part.3, The secret sauce…

First of all, no one can say “I have the perfect solution”. We are not dealing with a mathematical equation where we can have an exact solution. Rather, we deal with human brains, we interprets thoughts. It is a human interaction that can possibly carry different meanings and hence different results. That is why we just provide you some best practices and learned lessons.

Actually, all agile frameworks and methodologies are somehow best practices and learned lessons. It only gives you guidance and let you choose your way freely. Here i will share with you some of my best practices and learned lessons in requirements negotiations.

  1. Before you contract, just document the customer vision and high level objectives not the detailed requirements. we said in part.1 and part.2 that customer will always change the requirements and ask for new requirements, this is an axiom that we have to consider.
    As a development team, we usually like to have as much documented requirements as we can before we contract. We do that because.
    – We think that this will reduce future conflicts with the customer. Actually it will not 😦
    – We need to have more accurate estimation for project budget and schedule as early as we can.
    – This will help in building a robust solution architecture.
    It is good to have all of that, but documenting requirements early, will not result in that 😦
    From my experiences, i found that it is better to draw a frame for the project scope. what is inside that frame is accepted, and what is outside is not. The frame is defined by project vision, objectives, functional areas, system stakeholders and some high level user stories.
    “The vision and scope template of Microsoft frame work is a good reference”
  2. Raise customer awareness of software development challenges, but after contracting.
    It is not wise when you first meet your prospect to tell him about the tough and challenging nature of software development. He will most probably search for another company.
    After you contract with your customer, start raise his awareness about the nature of software projects but easily and slowly. Don’t give it to him in one shot. Be smart.
  3. Always Negotiate. Although in the vision document you defined a frame for the project scope, but still you will face many situations where you conflict with the customer about a requirement, wither it is inside the frame our outside it.
    When you face such situations, always think of the Trade-off triangle and negotiate based on it.
    – You have to make a trade with your customer about the new requirements. Ask for money or time.
    – Accept some requirements that are easy to implement without any trades, but after you negotiate it. Let the customer feel that he won the negotiations with you, and that you sacrificed for him.
    – In some cases when the customer is insisting on a requirement that is hard to implement, remind him with the situations when you sacrificed for him. This will make the negotiations easy for you.
    – Help the customer focus on high priority requirements and keep reminding him with project objectives…

Trade-off triangle

Good Luck

Software project management, the mission impossible, Part.2, Challenging situation


In part.1 we described the situation as building a plane in the air, and mentioned some of the challenges we always face. Here we going to discuss some of these challenges in details:

Requirements are not clear.

Always happening, customer usually has a problem and usually does not know the root cause of it. In best cases customer can has a vision with defined objectives. When you meet customer stakeholders, everyone of them has a different story to tell, everyone has a different expectation. And you are trying hard to listen to all of them to form your own vision, or a common vision that can meet most of stakeholder’s requirements.

Requirements always changing.

Remember when we said in part.1 that:

” The best ever written requirement document represents only 80% of customer vision”

When you form your vision that you think is the most close to everybody’s vision and then start to develop the requirements, customer will continually gives you feedback  and ask for enhancements.

This is normal, Customer can’t judge the system without seeing it at work.

As a development team we have to consider that and accept it as a fact an axiom in software development domain. Resisting it will result in project failure.

Project is out of budget and time.

This is a logical result of requirements being changed all the time. Although the customer himself never stops asking for new requirements, but after a while he gets bored of the project, and sometimes he loses his enthusiasm and motivation and may cancel the contract.

Happened to me many times 🙂

No time for test.

If the project reached that situation, where requirements are not managed anymore, and project is out of schedule and budget, and customer is complaining, Development team usually sacrifices wit the testing time to deliver and get paid…

You can imaging what would happen next.

Time is spent on Junk.

An academic study in 2003 mentioned that

“53% of project requirements usually be cancelled as stakeholders found that these requirements are not of much value for the project, or the situation itself has been changed where they don’t need these requirements anymore”

“64% of requirements built are not used, and in best cases they use once a year”

On the personal level, i once had a project where we were developing a campus management system for a college. we build more than 120 reports according to the customer requirements. After we finished, and while we were monitoring the system at work, we found that only 10 reports are being used periodically, and more than 50 reports have never been used all over 6 years.

So,,, what shall we do ?!

In the next blog, i will follow with you best practices and learned lessons.

follow the blog to get it on time.

Software Project management, The mission impossible. Part.1 Building a plane in the Air.


If project management is difficult, then software project management is more difficult. Actually, it is exceptional. Software development teams are usually trying to figure out a situation, analyze problems in this situation, listen to stakeholders, try to figure out stakeholders vision and thoughts about the optimum way to deal with that situation. Development team should translate outcomes of all these inputs into a running software program that works properly and solves problems.

Software development team deals with a customer vision. A vision that is not even clear and well defined. Customer only realizes that he has a problem, but in most cases, he does not know where exactly the problem is. As a result, customer always updates his requirements with time.

Software development team tries to figure out this vague vision and document it. Then works on developing a solution using technologies that keep changing every day!.

The customer environment and infrastructure is also hybrid, different running operating systems with different software solutions that are based on different database engines. And it is required that the developed system works in harmony with this hybrid environment.

And in most times, the customer has limited time and limited budget….

EDS once had a commercial that exactly explain this situation…

Yea,  Software development team are actually building a plan in the Air!

Think about it:

  • Vision with vague requirements.
  • Requirements keep changing.
  • Tools we use to build the solution keeps developing.
  • Solution need to be built while customer is running.
  • Solution need to be installed in a hybrid environments.
  • limited time and budget.

In order to succeed in software project management, you have to deal with these mentioned issues as facts and axioms, do not ever try to resist them, deal with them … Good luck

in part.2 of this article we will discuss samples of situations a software team would face with customers.