Can you make assumptions in the development plan?
It’s fine to make assumptions however, you must be mindful that with too many major assumptions, the plan risks becoming largely inaccurate which will ultimately cost time and money further into the development. Where possible, it’s better to control assumptions as much as possible from the offset to form a more accurate plan.
In particularly for projects where the values are high, if your estimate of work is out by a margin of 10-20% for example, this is a large sum so it’s worth investing the time into developing a fully detailed and accurate development plan to prevent budgetary and technical difficulties affecting key milestones and final delivery.
Alongside your flowchart and other documentation, you will be writing the top level development plan:
While you’re developing and using the flowchart to map and determine what needs to be done, you will be writing the high-level development plan. The purpose of this document is a top-level document that key decision makers are going to be analysing to allocate budgets and choose development partners etc. There’s an art to writing these documents and remaining concise! The design development plan should follow a loose structure of;
- An overview of what the project is
- Scope (the intended use of the device)
- Major deliverables
- Exclusions – these are important to outline from the offset
- Assumptions – its fine to make assumptions, it’s just important that everybody involved knows what areas your assumptions lie in. This allows you to go back and evaluate what assumptions were incorrect if problems arise. This also allows you to spot deviations and recoup some budget if you need to
- Organisational structure – to give an idea of who’s working on the project, how big the team is, how the team works together etc
- Acquired resources – these will be the externals that you need for example, your test houses and manufacturers
- Accreditation / documentation / procedures – demonstrate that you have certifications, procedures and a robust QMS system in place
- Flow Chart Outputs – these get migrated into a Gannt chart where you would list all line items and start assigning time and costs to each of the items. This is where a lot of the research will happen as well as discussions with your identified resources i.e. suppliers and verification houses to gain costs, timeframes, and other parameters to build into the Gannt chart. This is really just a snapshot of all of that information and work to give an overview
Again, this would be a live document that you will be writing alongside your flow chart, Gannt chart and other supporting documentation. Essentially, this is the launch pad to those documents so you would list them as external references. This is the master document that governs all of those documents and will provide all of the supplementary documentation for example, your proposal, the Gannt chart which would include the flow chart and any initial work that you’ve done alongside for example, a feasibility study.
So, this is the high-level master documentation which executives can read to understand how much it’s going to cost, how long it’s going to take and if it will be feasible. Then, if they’d like to dig deeper, they can begin analysing that supplementary documentation.
In a big company, there would likely be a head of a department i.e. head of design development (there could be multiple of these for various devices / elements) – they would typically ask an external consultant or, one of their team to determine whether this project is worthwhile investing in – it’s that person who would typically come to the likes of Haughton Design to ask us to do the work.
The design development manager would be typically looking at this higher-level plan while their executive will solely be looking at the first page and key details i.e. time and cost.
Typically, a pharma company will take this document, process it through their financial system to govern the financials to understand return of investment and market share. They will then plan it into the budget for the next financial year to decide on whether the estimated budgets are accurate and whether the project should move forward.