# Interplanetary Student Nanospacecraft: Development of the LEO Demonstrator ESTCube-2
## 4 Management Lessons
### Documentation during the Development  
Using a simplified documentation architecture for the CubeSat project is smart and should be taken from existing standards; nevertheless, the documentation remains a pillar for a successful project. The ESTCube-2 team decided to have simplified and minimalist documentation to save time for the development of the satellite. We noticed that by the end of the project, documentation had become scattered and without a standard structure, even leading to duplicated information.  
The general hope of CubeSats has been to simplify the projects, including their documentation. However, teams should not save time and money on documentation. Moreover, a \"documentation system\" must be carefully set up and maintained for the project's entire duration.  
As ESTCube-2 was built on the heritage of ESTCube-1, it was expected that the project would last only two to three years and could be kept simple. Moreover, assuming a short duration, written short-format documentation was deemed better. As the ESTCube-2 needed to be developed from the ground up, we could not reuse most of the ESTCube-1 design without additional work. This eventually led to the project needing more development time. As the core team members started to leave, the lack of documentation became a concern because most design choices stayed in the heads of leaving members. In a longer project, the traditional milestones of space mission developments in phases 0/A, B, C, and D appear well-adapted and should be taken as a management template for the nanosatellite developments. Such a management technique includes reviews at each milestone to address design issues promptly and avoid late re-design, fixes, and extra tests. We think such a project needs a \"board of mentors\" to review the development at every milestone.  
Like the software development industry, the team adapted modern cooperative development tools (Confluence, JIRA, Google Drive, Discord). Still, it did not yield the expected results, and pressure to use these tools might have even slowed development in some disciplines, like, electronics and mechanics. First, electronics and mechanical hardware design cannot be as rapidly iterated as software projects. Second, the high turnover of students and their part-time availability in the project make them reluctant to learn and use new tools from the industry. As a result, the documentation structure on a shared cloud became scattered between multiple environments, making sharing work and ideas more complicated and previously made decisions lost. At last, we think that in such a project, the project manager should be responsible for the structure, the maintenance, and the delivery of writing and reading permissions to the shared documentation space. This person must have a clear understanding of the project's stakes and milestones and some autonomy to organize the repository of the reference design and decisions.  
The industry does not want to change the established development processes due to frequent outsourcing, requiring adherence to well-known standards. Companies told us that our students should become familiar with standards, like ECSS, as it is used in the space field. Students must experience that proper documentation is a collection of complete documents. A good compromise must be found between the documentation conducted in the industry and the student project; otherwise, their contribution can be lost. Eventually, comprehensive documentation by predecessors makes integrating new team members much more manageable, as discussed in Section 4.3. If the documentation shows the value of the project, it becomes an asset when we need to show the work status and when we need to communicate our work to partners or the rocket launch provider.