

Guidelines for project collaboration between DF and Clients.

## Tools
* Project management & communication: Basecamp (invited as Client)
* Sprint planning & tracking: Jira/Basecamp
* Meeting: Google Meet
* Source control platform: Github/Gitlab (self-hosted)
* Design: Figma/Sketch

## Schedule
* Project kick-off meeting: **1 session**
* Sprint length: **1 week/2 weeks**
* Sprint planning meeting: **1 per sprint**
* Sprint review & retrospective meeting: **1 per sprint**
* Sprint **daily standup** meetings (can as well be done via communication channel or Basecamp’s check-ins)
* Project/team feedback meeting (with Account Manager): **1 per week** or **1 every 2 weeks**

Meeting notes for Sprint planning and Sprint retrospective will be sent within 30 minutes after meeting.

## Workflow
### Project Management
* All team members must be involved in Sprint planning
* Milestones and features (epics) should be put on Jira/Basecamp during Project kick-off phase
* New features/change requests will be put into Icebox/Backlog, estimated and planned for future Sprints
* Bugs can be added to the current Sprint depends on priority, complexity and available points of the Sprint
* The intention of every Sprint is “Potentially Shippable” Software, things can go wrong and features might get pushed to the next Sprint
* Every 2 weeks, the Team Lead, Product Manager/Project Manager and Account Manager will have a quick 15 minutes meeting to review the work progress and resolve any conflicts (if any)

### Design <> Development
* Design team should at least provide:
- Color palette (all that are used throughout the UI)
- Heading / Font size should be defined by scale
- Base components (.eg headings, button variants and states,…)
* New design version is expected to be available and reviewed **by development team** before the Sprint started

### Backend <> Frontend
* Prerequisite:
- API versioning & documentation (.eg Swagger)
- Dedicated environments for Development / Staging / Production
* Backend should enable CORS on either API gateway or at application level
* Both sides should agree on the same glossary / naming conventions / data schema, preferably within the first Sprint

### Quality Assurance <> Development
* Bugs/issues raised should include:
- Steps to reproduce, behaviorally described from - application’s entry to bug encounter
- Affected platform, version, feature, language (if applicable)
- Severity level
* For Frontend (web), each feature’s Pull Request will have a dedicated environment for testing. Use it to run feature tests before it got merged

## Release
* We release the end of each Sprint (on Sprint wrap-up day - the day before the Retrospective meeting)
* Hotfix releases are ad-hoc
* What’s included in a release:
- Semantic version tagging
- Release notes, changelogs, known issues
- Release’s artifacts
* Backend and Frontend (or each microservice in the system) will be released individually based on Semantic version

## Customer feedback
We received and responded to feedback via direct message, email or video calls. Specific feedback should be directed to specific PIC in a project team:

* Implementation/Development: Team Lead, Project Lead
* Sprint result: Project Lead, Account Manager
* Project progress: Project Lead, Account Manager
* Pricing/Billing: Account Manager
* Communication issues: Project Lead

## Issues management
We promise to respond and resolve in a timely fashion when problems arise, depending on priority & severity.
After issues are resolved, we will conduct an investigation and provide preventive measures (if applicable).

There are **4 levels** of severity:

### Critical: 4
Production system is down or a major function is unusable and there is no acceptable alternative method to achieve the required results. Support in such emergency issues is available via our hotline.

* Contact channel: hotline
* Response time: within 10 minutes
* Promised resolve time: less than 30 minutes

### Major: 3
Major features of the product are failed and/or performance issues impacting the normal functioning of multiple users.

* Contact channel: email, primary communicate channel
* Response time: within 30 minutes
* Promised resolve time: from 2 to 5 hours

### Moderate: 2
Moderate loss of application functionality or performance degradation. The system is still operating but doesn’t meet promised standard operation.

* Contact channel: primary communicate channel
* Response time: within 45 minutes
* Promised resolve time: within 7 hours

### Minor: 1
Minor issues such as visual incorrectness .eg color or font size, product feature requests and how-to questions.

* Contact channel: primary communicate channel
* Response time: within 1 business day
* Promised resolve time: within 1 business day

Subject to the above limitations, we promise to respond to support requests within twenty-four (24) hours.

guidelines for project collaboraton DF and Client

Collaboration Guideline

* Monday:
Sprint Planning
End-of-day (EOD) check-in message

* Tuesday:
EOD check-in message

* Wednesday:
Sprint review message
EOD check-in message

* Thursday:
EOD check-in message
Performance review (Account Manager, Team Lead, Project Owner, every 2 weeks)

* Friday:
Investment time/Tech Radar
Sprint Review
Retrospective

Dwarves Workflow


## Budget
We do need to know clients' budgets. This is often uncomfortable for them but their budget helps determines what scope is possible. It saves time. If they don't know their budget, we discuss different options.

We talk about breaking product rollout into stages and try to improve the product's chances of success at each stage by:

- Focusing on a small subset of features.
- Designing a valuable user experience.
- Developing a meaningful relationship with users.
- Budgeting for marketing tactics to tell users about the product.
- Designing interactions into the product for users to bring other users to the product.

## No Fixed Bids
Some consulting relationships start with a requirements document or RFP ("Request For Proposal"). The requirements are often extremely detailed.

The probability of this document containing the optimum feature set is extremely low. The right features are better learned through user interviews, prototyping, releasing actual software, and getting feedback from real users.

Based on that document, clients expect consultants in the industry to submit an exact timeframe and bid. This contract style sets the client and consultant working against each other right from day one. Instead of focusing on designing the product experience or evaluating what assumptions were wrong, they spend time negotiating about what was meant in a document written a long time ago or focusing on arbitrary deadlines. But it's worse than negotiating; it's retroactively discussing something that no one remembers the same way.

As you might have guessed, we don't do fixed-bid, fixed-feature-set proposals.

FBSC


Fixed-Budget, Scope-Controlled (FBSC) is applied at Atomic Object. They build custom software for our customers. Because of the complexity involved in building a great software product, software development projects are always more difficult to price than a product.

As a result two different strategies for pricing services, such as building software, have traditionally been used by most companies. These are called “Fixed Price” and “Time And Materials”.

### Fixed Price
* A Fixed Price strategy locks in the total price of the project upfront.
* Static Variables: Scope, Cost
* Flexible Variable: Quality
* Assumption: The estimate and plan are correct and will not need to be changed.
* Risk: On Consultant (Responds by inflating cost; may compromise quality if estimates are inaccurate.)
* Effect of New Information: Causes conflict about what’s covered by the scope vs. what requires a change order. New ideas are rarely incorporated.

In this strategy, the vendor is taking on all the financial risk of a project. They have committed to completing the project for a specific price. If they complete the job early, it’s a bonus for the vendor (and you the client has overpaid), if they don’t then the vendor loses. In order to mitigate this risk, they will want to know all that can be known about this project and the risks before it will commit to a fixed price.

Also, they will vigorously fight any variations to the scope of the project during the development of the software. When variations do occur, there will invariably be an argument as to whether this change is included in the fixed price that was agreed to or not. If not, then it’s time to generate the dreaded “change order,” determine the new pricing, and get the new pricing approved by the customer.

This is unrealistic, as it very difficult — almost impossible — to know everything that will affect the project at the very beginning of a project.  Also, it makes it difficult for the scope to change over the course of the project as new information becomes known that helps us to create a better software product.

Thus what appears to be a strategy for eliminating the financial risk to the client actually ends up introducing a new risk. By fixing the price and thus the scope of the project, we risk building the wrong product, or a product that doesn’t meet the needs of its intended audience.

### Time and Materials
In a Time And Materials pricing strategy, the vendor will work on a project and bill for every hour worked without regard to any financial constraints. An estimate may have been created, but since they are paid regardless of whether they exceed the estimated amount, they don’t do more than just track their time.

* Static Variables: Scope, Quality
* Flexible Variable: Cost (and Timeline)
* Assumption: The client can afford to do whatever it takes to accomplish the scope.
* Risk: On Client (Consultant has no incentive to be efficient or monitor budget.)
* Effect of New Information: Either more scope — and more cost — are added to project, or the information is ignored because there’s no more budget.

In this scenario, the client is taking on all of the financial risk. The client will most likely have an internal budget they are monitoring and thus are de facto responsible for ensuring the actual amount worked is tracking to the estimated amounts. Unfortunately, what is missing here is what scope has actually been completed. Without this information, the client cannot accurately gauge the progress of the project and thus does not know if the estimate is going to exceed the estimate until it actually does.

Also, the client may still be reluctant to make changes to the project scope in an attempt to not exceed the estimated amounts given by the vendor. But if they do make changes to the scope, the vendor will easily agree to these changes and complete them. Why not? They are being paid by the hour regardless of what gets delivered or if they exceed their estimates.
So while the vendor has mitigated their financial risk, the client now shoulders that risk.

### Fixed-Budget, Scope-Controlled
We don’t feel either of these pricing strategies helps us to build better software within a responsible budget. So Atomic prices the services using a Fixed-Budget, Scope-Controlled (FBSC) strategy. In this strategy we work with our client at the beginning of the project to get a good understanding of the project. Using this information and our knowledge about building software, we then create a responsible budget. We do not fix the scope of the entire project upfront, we only fix the budget and time.

* Static Variables: Budget, Quality
* Flexible Variable: Scope
* Assumption: There are more ideas than money, so we’ll focus on creating the best possible product for the budget. We’ll learn as we go and reassess our scope and plan regularly.
* Risk: Shared by Client & Consultant (and therefore reduced)
* Effect of New Information: Scope flexes as client and consultant re-prioritize features, possibly moving some to 2nd release. Price and schedule need not be affected.

As the project progresses, we track our hours worked on the project and the features completed on the project. We work closely with our clients, meeting with them weekly to discuss the status of the project. Part of that weekly discussion involves reviewing the financial health of the project. We are upfront on the amount of budget that we have consumed and the progress we have made towards completion of the project.

As the project proceeds, there are many opportunities to learn from what has been completed and ensure that we are moving in the right direction. In some cases, this information comes from additional user testing of the design, early iterations of the product, or discussions with the team.

The fact that we are not constrained by a contract with a fixed scope allows us to mold the project as we go along to take advantage of new information. The final outcome is a better product that better meets the needs of its users. Because we are actively monitoring and managing the budget, the client has the information necessary to feel comfortable with these scope changes, and we can determine the impact the changes will have on the budget.

Changes in scope will be reviewed to determine the impact they have on the project. If these changes increase the scope to the point where the budget may be exceeded, we are able to review the remainder of the project and make changes to the project scope that offset the increase.  We can either move other less-important features to a later release, or we could reduce the complexity of a specific feature to help bring the project back in line with the budget.

Actively managing the budget on a weekly basis does not normally happen in either a Fixed Price or Time And Materials pricing strategy. In both cases the tendency will be to discourage any changes to the scope to eliminate increases in the price of the software. This is unfortunate because we learn a lot as the project progresses that can have a positive impact on the final product.
While a budget is not a fixed price, it is a number we actively work towards meeting. Atomic has a great track record of meeting its budgets.

We feel this pricing strategy helps us to collaborate and cooperate better with our customer. The financial risk is now better managed and does not fall solely on a single entity. Working together, feeling free to make scope changes as we progress, and having the information necessary to manage the scope and budget makes for a much better working relationship and ultimately a better product.

Source: [https://spin.atomicobject.com/2014/08/25/fixed-price-vs-time-and-materials/](https://spin.atomicobject.com/2014/08/25/fixed-price-vs-time-and-materials/)


Fixed-Budget, Scope-Controlled (FBSC) is applied at Atomic Object.

Fixed Budget Scope Controlled


## TRAINING COURSE: HOW TO WORK WITH CLIENT
What skills that an engineer should have in order to work with client effectively?

1. Strong technical skills: includes
- Basics of testing: Unit, Integration, System
- Software testing and debugging
2. Attention to details
3. Communication skills: good English skills (both written and verbal)
-> require somewhere Intermediate - Upper Intermediate level
4. Problem solving and logical thinking
5. Work planning
6. Teamwork
7. Project Management
8. Consistency in delivering work result

What are the issues that our engineers currently facing when working with clients?

1. Verbal and written English
2. Attention to details: many times not able to deliver clean works
3. Work planning
4. Consistency in delivering work result
5. Teamwork (i.e: Dong Nguyen case when working with Ukraine team, could not synchronize with the rest of the FE team very well, mostly due to not being able to communicate very well)
6. Lack in EQ


What skills that an engineer should have in order to work with client effectively?

How to work with clients

Invoice


We are all aware of the uncertain economy, as well as the long funding winter in the tech market. These forces have led to companies being extremely cautious with their tech budgeting and resources. We have seen more than enough budget cutdowns and layoff across the tech industry.

There still is an upside to the matter. When there is a need to build, companies now prefer partnering with teams who can deliver comprehensive, end-to-end solutions. This means the role of Dwarves is no longer deploying engineers who can code. We now can also offer research, business analysis, consulting, solution design, and much more.

Given the growing dynamic of our engagement, fixed prices or monthly retainers became much less sufficient. That’s why we are now implementing an **hourly billing model** so we can be:

- **Fair**: we get compensated for the actual hour spent, reflecting the real effort and level of expertise we bring.
- **Flexible**: we can adapt to scope of responsibilities, client requirements and project scopes.
- **In control**: we can make sure we are paid for additional work required to address issues and challenges.
- **Transparent and foolproof**: clients get detailed time logged, no grey area. Numbers create transparency and trust for both sides.

### Implementing the Hourly Billing model

We are using the following steps to successfully implement this model.

- **Clear announcement**: ensure our clients are fully informed about our timesheet approval process, as well as how we track time.
- **Timesheet setup:** different projects might require different timesheet formats. We need to work with the clients to set the correct format for timesheets.
- **Time tracking**: we use Notion / Excel to record hours spent on each project and task. If a member is on the hourly billing, said member is required to log their time in an accurate and timely manner.

  ![](assets/time-log-for-design.png)
*Example of a timesheet we are using for design work*

- **Project management:** maintain detailed project plans, frequently update clients of progress, changes in scope and how that would effect the hours to be billed.
- **Approval:** timesheets are sent at the end of the month for client’s approval. Only after timesheets are approved that we can send invoices.

  ![](assets/email-for-approval.png)
*Only after timesheets are approved that we can send invoices.*

This hourly billing model is nothing new, but it require us to be consistent and articulate. Build it up like a habit, and we will be able to take greater responsibilities and better client relationships.

In case of any questions or further clarification, our ops team is ready to assist.

A new hourly billing model is introduced to ensure fair compensation for effort, flexibility in project scope, control over additional work, and transparency with clients.

Pricing model: Bill by hours


## GENERAL QUESTIONS FOR SERVICE FEEDBACKS
1. Engineer performances

   - a. Communication
     - How did the engineer interact with your team?
     - How was the communication between the engineer and your team?
     - Was our engineer proactive in communicating with you?
     - Did our engineer ask lots of questions?
     - On which aspect our engineer should improve to provide better communication?

   - b. Work ethic, delivery
     - Have our engineers “coming to work” on time?
     - Have you ever had to wait too long to get a response from our engineer?
     - Was our engineer able to deliver good work consistently?
     - Was our engineer able to deliver clean, good code?
     - Was there a lot of bugs that arose from our engineer’s work?
     - Were these bugs considered as “rookie mistakes”?
     - What can our engineer do in order to provide better code?
     - Have our engineers been able to discuss work planning before starting on the coding?
     - What should our engineer do to improve the synchronization with other members?

2. Team management
   - What are your opinions for the team management?
   - Was our Team Lead able to help you co-manage the team efficiently and effectively?
   - Was there anytime that you cannot contact our team members in a timely manner? If yes, please specify.
   - When you are unhappy with the engineer’s work, who would make you feel comfortable to contact and discuss?
   - Was it easy for you to contact our Account Manager?
   - Was our Account Manager able to note down your request thoroughly?
   - In the end, was our Account Manager able to help you solve the problems?
   - What should our Account Manager do in order to improve the collaboration between two parties?

3. Opportunity
   - Would Dwarves Foundation be your first choice when it comes to hiring outsources? If not, why?
   - What should the Dwarves Foundation do to improve its credibility to you?
   - Do you have any further comments for the Dwarves Foundation?


Service Feedbacks


One of the most important questions at the start of a project is how much it will cost. It is vital to make sure that enough budget is available to allow for the development of a viable product.

The difficulty with setting a budget at the start of a project is that everyone is at the point of maximum ignorance. At the beginning of a project, all of the requirements have not matured. Scope may not be fully defined, the market approach may be a bit hazy, or the technical requirements may still be in flux. It is okay to move forward with a loosely defined project as long as the scope and budget are refined at several steps along the budget roadmap.

### How Big Is the Pie?
After a project has been loosely defined, the profit generating, or cost savings, potential should be estimated. Refining scope and budget will cost time and money. Knowing the potential reward will ensure that the research, design and planning effort stays within perspective.

### Early Estimation
We use the early project requirements, historical data from previous projects, and our experienced intuition to initially estimate cost. At this point the estimate will have the broadest range. We might estimate that the project will definitely cost $50,000 but probably not go over $100,000. If the estimate is much higher than expected, we can revisit the requirements to make sure that scope expectations are aligned. We can redefine the scope and estimate again.

![](assets/setting-the-budget_9e1847473feeac53a6defef0ef0848c4_md5.webp)

### Research, Design and Planning
If the initially estimated cost range is acceptable, we’ll move forward into a research, design, and planning (RDP) phase. This phase provides further definition of the product’s users and functionality. We will create a story map to define the user activities and tasks and use that map to define a minimum viable product. We then estimate the development effort, in ranges of days, to implement the features that allow users to complete the defined tasks. To aid in our estimation effort, we may create sketches or wireframes that roughly define the features. We’ll also qualify each feature as supporting the context or core of the product and how high or low the frequency of use may be.

### More Decisions
Our refined estimate coming out of RDP usually falls within the range of our initial estimate. Sometimes the estimated cost increases because we have learned more about the product. A higher estimated cost is okay. Money has been spent to gain knowledge. Risk has been reduced and we’re more certain about the cost of chasing the reward. At this point a decision is made to move forward with development or not.

### Predictable Delivery
We start development with the estimated budget from RDP as a constraint. We create a backlog of development stories. Stories to be completed in the near future are more defined than stories in the distant future. We track our progress through the backlog of stories on a weekly basis. We give weekly updates of the projected final cost. We define stories further when appropriate and negotiate scope to keep the project on budget. At the end of the project, we deliver a final release within a predictable time and budget.


After a project has been loosely defined, the profit generating, or cost savings, potential should be estimated. Refining scope and budget will cost time and money. Knowing the potential reward will ensure that the research, design and planning effort stays within perspective.

Setting The Budget


During our study about innovation, we find the topic of adjacent possible. Innovation happens but not many people can point out clearly. Getting to know the foundation of innovation helps understanding its natures and could lead to further exploration. Enjoy your reading.

Innovation deepens our knowledge and understanding of the world, it extends our reach and access to resources. More importantly, **innovation expands the realm of what we can do** with all our knowledge and resources: deliver new goods and products, bring forward new types of organisations and services, and in more general terms develop new ideas and concepts.

Now, expanding any realm always requires leaving its current boundaries in order to explore ‘*the possibilities out there*‘. But rather than chasing the most extreme or distant possibilities, successful exploration focuses on the immediate vicinity of the current boundaries: Expansion can then occur by naturally ingesting nearby possibilities, by a short stretch of the realm’s new boundaries. Therefore, the **adjacent possible** is the target of successful exploration and expansion.

The concept of the adjacent possible originates from Stuart Kauffman and his work on biological evolution. Kauffman was particularly interested in the origins of order and the mechanisms that drive self-organization. His findings are broadly **applicable to any complex adaptive system**, be it natural like the biosphere, or human-made like cities, the economy, or technology. Kaufman investigates how *the actual* expands into the *adjacent possible*. *The actual* describes the system under investigation in its current state, with all its components and interconnections. *The adjacent possible* contains all the elements outside but near that system; those represent the opportunities for the current system to expand by building new connections and turning those elements into system components.

Now let’s **apply this abstract notion to technology and innovation**. And let’s take today’s ‘technosphere’ as *the actual*, comprising all the tools and technologies we use in modern-day societies, together with the knowledge, concepts, facts and ideas required to devise, build, operate, and maintain them. Right outside that ‘technosphere’, in its *adjacent possible*, you’ll find the space for innovation, for combining known technologies in novel ways, and for developing and implementing novel problem-solutions that yield novel technologies.

### Progress
The in-going statement frames **the very essence of progress**: the future flows from the past, we shape it on the foundation of the past. The progress we achieve is path-dependent, it evolves step by step, but it cannot jump. We didn’t go straight from caves to skyscrapers. Galileo didn’t move on to devise radio telescopes. Early cattle breeders didn’t know about genes, let alone think about gene editing. Such developments take time as they go through many, many stages. But all the steps taken for all such developments (including intellectual dead ends, as well as short-cuts, highways, dirt roads, bridges, or tunnels) are available to us today as building blocks for our future.

Such progress is not just a lucky coincidence we enjoy at the beginning 21st century. Since the early days of humanity, our ancestors worked with what they had available to their hands and minds. The only difference between life in pre-historic caves and say, Singapore today is the tremendous accumulation of building blocks that occurred over several tens of thousands of years. That points us to the *secret ingredient* of human progress: **our capacity for social learning**. This uniquely human ability allows us to share our ideas –even over long distances in both, space and time– and to build new ideas upon them. Social learning is the ‘secrete sauce’ that got us to where we are to today; and it will pave our way to where we’ll be tomorrow.

To shape our future, we *“only”* need to find out how we can best combine the available ingredients to get the next task done. That’s what we call progress. And we can make progress in different ways.

### The adjacent possible
To illustrate the different paths we can take to make progress, I’ll borrow the concept of the adjacent possible that Stuart Kauffman originally developed to describe biological evolution, and transfer it to human non-biological development: some call that our cultural evolution, and that’s what I mean with progress.

Let’s start with all the available ingredients I mentioned in the introduction. This collection of building blocks is what Kauffman refers to as ‘***the actual***‘, and at the scale of humanity, that contains an impressive lot: anything that makes up our economies, our societies, our cultures, our technologies, plus the natural resources we have access to.

Outside of this ‘what we have’ is the realm of ‘***the possible***‘, i.e., anything we could create by combining some building blocks (those available in *the actual*) in new ways. This is the realm of ‘what we could have’, but anchored in the reality of *the actual*. Now think about what happens when one of those ‘possible things’ becomes real, for example, say, the integrated circuit. It immediately becomes a part of *the actual*, and *the actual* grows just a little, now that there’s one new ingredient. At the same instance, *the possible* grows superlinearly due to the myriad of new combinations the ‘old’ ingredients could form with that one new building block. That’s how the integrated circuit gave rise to today’s information technology. That’s how progress breeds yet more progress: new ingredients tremendously expand our possibilities.

However, the realm of *the possible* is far from homogeneous; not all possibilities are equally achievable. Near *the actual*, you’ll find ‘***the adjacent possible***‘, which is the zone of (comparatively) easily achievable possibilities. These are the possibilities ‘within reach’, or ‘just one step away’. *The adjacent possible* is the domain of innovation.

![](assets/the-adjacent-possible_ec265ab423ab94bc12c32ecaeec5378c_md5.webp)

*The adjacent possible is the zone stay in between the actual (the current state of the art) & the possible.*

### Sketching five paths to progress
But innovation is not our only path to making progress. I’d argue that there in fact five such paths:

* sharing,
* science,
* invention,
* discovery,
* and innovation.

The following chart locates those five paths within the scheme of

* *the actual*,
* *the possible*,
* and *the adjacent possible*.

**Sharing** – The simplest path to progress is the use of best practice examples and the wider **distribution of ready-made recipes**. That’s progress for the individual who didn’t know that specific recipe before. Such sharing of useful knowledge does not immediately generate progress for humanity. That’s why this path remains located in *the actual*. Still, sharing plays a vital as it improves the conditions for further progress to occur. Sharing facilitates social learning: more people knowing more are more likely to generate more –and more useful– ideas.

**Science** – At the opposite extreme we directly seek to **expand the boundaries of human knowledge**, to push the limits of *the possible*. That’s the role of science and in particular of fundamental science, which is committed to enhancing our knowledge and understanding of the world. Though the results of scientific research are often not immediately useful to practical everyday life, science lays the foundation for further, more tangible progress later, for example through applying that newly gained knowledge to address emerging problems.

**Invention** – As humans we like to **pursue original ideas** that we believe in; for example, a new method we can develop or a new tool we can create. Some of these inventions turn out to be unattainable, because the underlying assumptions are seriously flawed: think about all the ideas for perpetual motion machines, which must inevitably fail due to friction, heat transfer or other forms of energy loss. However, inventions that succeed can create entirely new technologies (such as Count Zeppelin’s “steerable air train”), and some actually transform human society in previously unthinkable ways (like the wheel or the internet). Because inventions cover such a wide range (you might say: from crackpot to genius), they are located any place in *the possible*. Hence, progress generated by inventions may take many forms: from quite abstract (learning that the original idea cannot be realized) to very tangible (the original idea actually solves a concrete problem).

**Discovery** – Sometimes we **make an unexpected observation** that is difficult to interpret or comprehend. Such discoveries challenge previous views of the world, as they are unintentional (think about Röntgen and X-rays) or even accidental (Columbus setting foot in America, not China). Discoveries are unplanned: rather than us looking for them, they seem to find us without any conscious effort of ours. Therefore, they can only be situated in *the adjacent possible*, in the space that is within easy reach. As they hit us unprepared, they may cause confusion and give us reason to pause. But wrestling through them, we progress to an advanced level of understanding that, similar to the outcomes of science, provides the fuel for further progress later.

**Innovation** – And then there is purposeful, intentional work in *the adjacent possible*, deliberate efforts dedicated to achieving concrete progress. That is when we **develop and implement novel problem-solutions**; that is innovation as I [defined](https://understandinginnovation.blog/2013/09/25/a-working-definition/) it earlier.

Of course this distinction of five different paths to progress presents a simplified scheme; in real live, these paths are heavily intertwined as they pave **the winding road to progress**. Sometimes they run in parallel; sometimes they occur in sequence; loops and iterations are always possible. And there are many contributors, some making very directed efforts, some offering accidental findings. Success will only arise from the collective outcomes of otherwise disjointed efforts: innovation draws its punch from all the others paths to progress.

Against this backdrop of *the adjacent possible* and the different paths to progress, I’ll get closer to the role that technology plays in our innovation efforts. Is it an enabler or in hindrance? What we could realistically expect, and what we should demand from technology? More to follow in the next post.

**Source**: [Understanding Innovation](https://understandinginnovation.blog/)

The concept of the adjacent possible originates from Stuart Kauffman and his work on biological evolution.

Playbook > Business