Drug development

Biotech: Drug Development Process to Phase 1

Use this template dynamically with Proggio!


Bio technology drug approval projects are likely to take several years. Starting from initiation all the way to public use, drugs need to go through different approval processes in different countries pinpointing different targets of interest.

In this template we will cover the drug development process to become a Phase 1 ready only – from initiation to Phase 1 trials.

The Phase 1 project includes several major workstreams:

  1. CMC – Chemistry, Manufacturing, and Control
    • Development and manufacturing of the drug substance
    • Development and manufacturing of the drug product
    • Analytical methods development for substance and product
    • Bio-analytical methods development for rodents and non rodents
  2. Pre-clinical – enabling the later clinical phase and collecting information for the regulatory process
    • PK (pharmacokinetics) – what the body does to the drug
    • Pharmacology – what the drug does to the body and the disposition of a pharmaceutical compound within an organism
    • Safety and Toxicology – the degree to which a substance can damage a living or non-living organisms
  3. Clinical and Regulatory
    • Clinical preparation, protocol and operation
    • Regulatory preparation and submission

Following these workstreams, the project can be controlled with relevant milestones – pre-clinical ready after approximately one year, clinical ready after another year and Phase 1 ready after 2 years or more.

Links and dependencies between activities are presented in high level. Each quarter should be carefully planned to efficiently make progress toward phase 1. Building the CMC process correctly, enables to start the pre-clinical activities earlier and saves time when heading the clinical phase. Once the pre-clinical phase started the focus moves toward the regulatory submission and all activities are targeted to accurately collect and prepare the materials for the  Investigational New Drug (“IND”) application.

Getting IND approval actually moves the process into Phase 1 and beyond this template scope.

App Development Code

Application Development

Use this template dynamically with Proggio!


Application development includes a lot more than writing code. Yet, jumping into the coding lines is a common mistake that tends to result in time loss, and mismatched requirements and implementation.

This template suggests a process that starts with application definition and ends with a user test. The template spans a six-month plan, but the actual duration varies according to application size and complexity.

It is highly recommended to break down the project development process into phases and to refer to these phases throughout the management process, for example – UX, UI, Development and sometimes a user test. Breaking down the scope of the project provides quick feedback on ongoing work and allows for changes to be made before the entire project is out.

The following categories are likely to be included in application development:

  • Definitions and tests – good implementation must start with detailed requirements, otherwise we don’t know what to build, why, when and how to test it. Requirements are documented to avoid misunderstandings, misconceptions and to ensure data preservation. The test plan is developed based on defined features.


  • UX and UI – never count them as one! UX translates the requirements into the project’s wireframes, without the final graphics (UI). UX involves refinement of project requirements to make it more relevant and understandable to users. The UX process ends with a user test before any UI work is done. Only after real users approve the UX design does the UI process kickoff.


  • Development – this template shows the development integration but does not specify how the code writing is managed (preferably with Agile methods). The process starts with technology exploration and decision making, based on the requirements. It then continues on to mockup, which requires basic wireframes but does not require any UI design. The development process should also follow several phases, so the outcome can be tested as soon as possible. As long as the user test with the UX model is not completed, it is important to continuously focus on mockup and technology challenges. Once verified with real users, part of the application features can be released to development knowing that from this point, big changes are unlikely. The development process is also a good time for buffering management, to make sure the alpha release will be on time.


  • User engagement – should be managed as early as possible. Relevant alpha candidates can also be the test users, as long as they are not exposed to the application during development. Successful user testing of a UX model and alpha testing with real implementation will increase the confidence in the application’s usability and ensure project success.


  • Operation – cloud services or on-site resources – the application should have a stable platform to run on and the relevant personnel to maintain it.

Building an Electronic Device

Use this template dynamically with Proggio!



We are surrounded by devices. Building a new device requires high-level technology integration. A device can be anything from a kitchen appliance or a payment terminal to a digital watch or music player. Computer peripherals are also devices as well as the growing market of Internet of Things (IOT) and sensors.

Building a new device from scratch will probably require several months of work. Even if the electronic design is simple, the process required to stabilize a new mechanical design combined with an electronic board and software takes time. While small devices can be developed during an annual quarter, complicated devices and big appliances can take more than a year and may involve very large development teams.

This example shows a typical 9-10 month project plan, which should be adjusted for the specific device being developed to get a realistic projection.

A typical device project plan should include at least the following categories:

  • Electronic design – the electronic design process includes the logical design, followed by placement and routing. We recommend planning at least three design cycles. The first cycle aims to establish the initial functionality and enable initial testing. The second cycle aims to stabilize the design so it can move through real testing, stress and corner cases. The third cycle aims to yield a production process for an electronic board, combined with a stable package.


  • Electrical manufacturing –unlike software, building an electronic device requires engagement with a factory or at least prototype services to build and test the design. Working with a manufacturer has its own tolls and it should be managed within the design cycles.


  • Mechanical design – while making the first steps in electronic and software design, the team should also plan the mechanical design. It starts of course from the device casing, but other things, like transportation packaging, should also be considered. The mechanical process involves at least two steps. The first one is using a quick mold (silicon for example), which paves the way to mold manufacturing. When designing a low volume device, a quick mold can also be considered.


  • Mold manufacturing – takes time and should be planned carefully with the mold manufacturer, not only for tailoring the initial creation, but also to foresee the time-consuming changes and other changes that will not possible. The mechanical team should report on progress steadily, especially if the device has complex mechanical requirements (free fall for example).


  • Software development – whether an open source operating system like Android, a proprietary system, or just an embedded code to run the microcontroller and chipset – they all need a complete software development plan in parallel with the hardware development plan. Software development may start with technological exploration to find the right technology, libraries and components. Once the codebase is established, the team needs to start sprints, preferably using Agile methods, while taking into account the hardware build progress.


  • Hardware test – is critical for keeping manufacturing costs low and for avoiding long term liabilities for the company. Requirements can vary, so the team first needs to agree on the test level. Should it work underwater? In dusty/damp/other conditions? Free fall? How many clicks each button is expected to experience during the device life cycle, etc. Once the requirements are in place, the hardware test owner should define the test procedures that can be done in-house and those that require a lab. Only then can the preparations start towards first samples.


  • Software test – working closely with the software development team, the software test team should develop the test cases required to verify device functionality, UI and error codes. Not all device software is available for updates, therefore the software test should be stricter than say, a website test.


  • Certification and qualification – all devices go through some certification process. A common one is the CE/FCC electromagnetic certification. Different applications can require more advanced certification, such as military, payment systems, fuel stations, in flight use, etc. The list of requirements for each certification is turned into the design requirements which are verified in lab sessions. It is recommended to plan at least two lab sessions – the first one for finding gaps and the second for passing the certification.


  • Peripherals and power supplies – are important and can be very tricky if the device is sold worldwide. Every country has its own power supply adapters, regulations and cables. Do not leave it to the last minute and always leave a buffer.


  • Documentation and packaging – finally, the device is going into a box with some papers. These can be a safety guide or a quick installation guide. Package design should consider low logistic costs, in-store presentation (if relevant) and transportation conditions. Good documentation can save the company’s support team a lot of time.