Introduction
Virtual reality is a fairly new technology that has gained popularity in all fields of our economy. Bright auction thought of developing virtual reality software that entrepreneurs can use to assess the worth of their business plans. The bright auction comprises key individuals who deal with specific aspects of the virtual reality business plan software development.
Aljazi and Noor are the team researchers who have been delegated to find the information regarding marketing, financing, and the best partners we can work within this project. Ahmed has the task of nurturing harmony in the team by providing a helping hand when one is stuck. Khalid is our software expert who is involved with the development of the virtual reality business plan platform. He is involved with the coding and writing of the software, and he is a key member of this team. Finally, I am the leader of the team who must advocate for group reflective learning. I also ensured the team attained its target and good communication among the team members.
This project has not been easy, and we have faced several challenges, as expected, in software development and the launching of the online platform for clients to access. Three challenges made us learn a lot in this project. They include conflict with the software testing team, limited infrastructure and resources, and time limitations. As the leader, I had to motivate the team members to approach the challenges from all angles. However, a constant collaboration between team members to find the best solutions to our challenges was our best tool. This made us develop the best virtual reality business plan that our partners appreciated. The plan was business worthy and had a high probability of return on investment.
Conflict with Software Testing Team
Software development is a highly complex and high-skill endeavor; however, luckily, we had Khalid for our team. We initially had three options we thought should be used for our software launch: using cloud computing, establishing company servers, or downloading virtual business software. According to Khalid, for our software to achieve the intended objective, it should attain three key functionality: the ability to be accessed globally, minimum hardware requirements and the ability to execute a virtual reality plan. It was up to the team to use reflective learning to understand the capabilities of each launching platform (Daniëls et al., 2020). As the team leader, I was tasked with selecting the best software testing team available in the institution. I selected Einstein’s group testing team because it was ranked the top in last year’s software engineers’ competition at the university and the Bright auction team embraced the decision.
In the Einstein testing team, we achieved global coverage when using the cloud computing launch system. The cost of computer hardware required was also minimum, and estimating the individual client business plan was up to expectation. In our second option of establishing Bright auction servers to launch the virtual reality business plan, global coverage and software functionality was also achieved. However, the cost of hardware required was high to purchase. In the third launch option of downloadable software, the global coverage was achieved, but the functionality and cost of hardware will be high for our clients. This was a valuable reflective observation for the team (Fridge & Bagui, 2016). This information was documented in our software test assessment datasheet, and the testing team recorded the comments.
The Einstein team proved to be resourceful because, during the reflective learning, Kahlid and I saw how the software was executing its command and developing various business plans as requested. However, there was a conflict with the software testing team. Einstein’s team felt that a tool was needed to be removed in the software used to compute financial statements. According to the Einstein team, the expected financial statements did not reflect the actual financial status of a business. As the team leader, I felt that not providing this tool to our clients would be a disservice to them because they need to forecast future revenues and assess the value of their investments. I had to convince the team to learn from our experience to solve the problem (Daniëls et al., 2020). This was a coding problem, and we could solve it by learning more from the software’s functioning.
According to Einstein’s group, there were two options: either create a financial statement tool as an individual software or completely remove it from the virtual reality business plan. This was a dilemma that split the team into two factions. One advocated for removing the financial statement tool, while the other was developing new software that could make our software less dependable. According to Khalid, the software could be developed to be adapted to the accounting system of each country. However, it will be costly because we will have to customize each software for each country. This was truly a first-hand, life-learning experience in the world of computing (Fridge & Bagui, 2016). A decision had to be made based on the available information. However, whatever the decision, our software testing team had to be part of it because they were advocating for removing the tool.
In our daily meeting, we invited the Einstein team to decide to avoid the emerging rift. Ahmed had to use his diplomacy skills to bring everyone to the table because Einstein’s group did not want to be part of the process if we insisted on retaining the financial statement tool. I felt some concessions had to be made if this project continued. As a team leader, I have learned to have concessions for the betterment of the team (Daniëls et al., 2020). Khalid and I convinced Einstein’s group and the rest of the Bright auction team that we customized the software for countries that use the Generally Accepted Accounting Principles under the Financial Accounting Standards board. Countries that use the International Accounting Standards Board’s accounting principles had to wait for the financial statement tool. The tool will be gradually incorporated into those countries’ virtual reality business plan software as the Bright auction expands globally.
Khalid and I had to concede because we were advocating for the maintenance of the tool, and it was one of the aspects of the software we worked on. Nevertheless, we had to allow for concessions because of the financial statement tool’s limitation operating in other jurisdictions. It was hard work, but that is the importance of reflective learning; through experience, you get to know whether your concept on the paper is executable (Daniëls et al. 2020). This may impact our revenue generation; however, we predict rolling out the customized software for IASB countries one year into our operations.
This process with Listen group has been very resourceful because I have expanded the scope of how I view software development. I have understood that every problem has its sub-problems, and they all need to be addressed gradually. In the future, in my abstract conceptualization, I will try as much as possible to solve a problem that does not have several adjoining problems because it makes the solution cumbersome to execute. In the experimentation stage, I will expand the scope of the study to cover all the scenarios possible. This will expand my working experience with more than one scenario (Daniëls et al. 2020). Finally, I will have enough data on the reflective observation to decide which software tools to remove or add to improve the clients experience.
My reflection on the experience with the Einstein group is that working with a qualified and dedicated team is very important. Learning is a continuous process acquired through experience and trial (Daniëls et al., 2020). Initially, Bright auction thought that the virtual reality business plan was proof of flaws; however, we did not factor crucial accounting principles in our financial statement tool; hence we have to roll out your product to limited countries. However, this group’s reflective learning has expanded our scope of vision. In the next software development, we will first study other non-core regulations that may affect software launching.
Limited Infrastructure and Resources
Software development and testing require advanced laboratories, which some are not available at the university. Additionally, students pursuing computer-related courses are given more priority to use the laboratories than students from other fields. Therefore, accessing the computer laboratories adequately to execute our project optimally was a challenge. Another resource that was a challenge was accessing the cloud computing system. The university has institutional-based servers, and hence cloud computing was also proving to be a challenge to access. However, as students of reflective learning, we had to turn challenges into a learning process (Eyler, 2002). The whole process has been problem-based learning with relevant practical tools. As the leader of the group, I had to work closely with the team to identify solutions quickly to bring the virtual reality business plan software online.
To address the challenge of accessing the computer laboratory at the university, we requested the head of computer laboratories to allow the Bright auction to be accessing the laboratories during weekends and in the evening hours. Our software was not as complex as those used in automated driver assistants in electric cars; however, it also required a great deal of time in coding and development. In relation to accessing the cloud computing services, we had to request the local cloud computing company; there was a cost implication in this solution. The solutions were necessary but not popular with the Bright auction team, but we had to strive to bring this software online despite the limited resources (Daniëls et al. 2020). I was committed to leading my team through these trying times where our fate depended on the urgent availability of computer facilities.
Our working schedule was expected to develop virtual reality business plan software in 6 months. This was not possible with the limited access to the university computer laboratories. Our key partners’ the development bank of Qatar and the local software company that was to assist with launching the product once completed, felt that we were not attaining our objectives. The development bank of Qatar had initially given us twenty thousand for the software development, and we had already exhausted the funds, and we had to request more funds. There was a conflict that had to be resolved; I, the team leader, and Ahmed had to request an extension of time by our key partners. Using our problem-solving skills learned through reflective learning, we convinced them to extend the deadline (Eyler, 2002). They understood that the university facilities and local cloud computing services have difficulty accessing them.
The development bank of Qatar agreed to extend another loan facility of ten thousand; this would increase our initial startup capital to 160 thousand, which was a substantial amount. The local software company that we were supposed to partner with agreed that we would use their computer facilities if the university facilities were still unavailable. However, it was impossible to move the project to them because we had already begun coding using the university facilities. We had to learn from these challenges to improve our future efficiency by sourcing dependable computer resources (Eyler, 2002). However, we completed our project using the university facilities and the hired services of a local cloud computing company that cost us ten thousand.
Through reflective learning, I have understood how I will address the problem of limited resources in the future. As the team leader, I will prioritize planning and developing contingency plans if the first plan fails. In the abstract conceptualization stage, we will allocate enough funds to develop our laboratory facilities to depend on the university facilities or third party in our future software development. During the active experimentation stage, as the team leader, I will ensure future software development facilities are equipped with the latest technology to avoid snarl-up, as evident in the university’s VR room because of increased loading capacity (Fridge & Bagui, 2016). In the concrete experience stage, I will ensure there is maximum collection of data and timely observation of how our computer facilities respond to task execution and whether there are downtimes. Finally, I will assess the performance of our computer resources where they are optimal in the reflective observation.
My reflection on this problem-based learning process is that, though we are a startup, we need to improve our software development efficiency and effectiveness. This is because our inefficiency has caused us an extra 10,000. It is costly to depend on a third party and institutional facilities because they were meant to serve their needs. Therefore, requesting their services will be considered last; hence, it is good to own our facilities. The success of a project depends on the leadership and the team unity plan (Daniëls et al. 2020). A team that knows how to work with little is better suited to achieve results since they can work under pressure.
Time Limitation
The software industry is very competitive, where success or failure is determined by how a company manages its time. Software should be developed when there is still relevance in the market or lose its intended purpose. The bright auction was given one year to ensure that the virtual reality business plan had been rolled out globally. Our financial and software partners understood the essence of time, which proved to be a challenge. We had to do this right for the first time, even though we are a startup. Time pressure was a useful reflective learning experience (Lynch et al., 2021). However, there was team burnout because of delays at the university laboratory.
As the team leader, I felt that I had to address time issues since I wanted everyone to on board. As a team, we developed the critical path analysis for project development; this proved to be a useful tool because activities that could be executed simultaneously by different team members were done, saving us a great deal of time. Another time-saving method was incorporated by developing a schedule, especially during software testing. Two team members would accompany the software testing team, and the remaining members would take a day off to reduce fatigue. The time management techniques were truly revolutionary, and we had to improve because the schedules at the university laboratory were becoming more squeezed (Lynch et al., 2021). Although we could develop the software within the stipulated time, there was some damage to the team and the project.
The best reflective learning is gained when individuals work under pressure; however, there will be mistakes. One of the challenges of time limitation to the team was the development of burnout syndrome. Aljazi and Noor slightly suffered from the syndrome, and they had to be given time -off from the project for two weeks. I also developed a serious fever and fatigue, and the best bed rest was recommended thrice throughout the year the project was being executed. Khalid, our software expert, was the most affected; he suffered from light sensitivity because of long hours at the university computer facilities coding the software. I feared that the quality of our software would be compromised, so we had to learn from our experience to develop another time management solution (Daniëls et al. 2020). We extended the release date by another three months. We were only left with two weeks of software testing, which could be detrimental if were launched a product that was not given ample time for testing. Fortunately, the product turned out to be okay.
Time management is a critical component of any project, especially for software development companies to stay afloat. If there I intend to optimize future software development, it is time management. I do not want to repeat testing the product a few weeks to launch. In the future, during the abstract conceptualization stage, I will ensure necessary measures have been taken to for adequate project completion time. If an activity has been delayed, the team will have to recover the lost time by working on weekends and reducing day-offs. As the team leader, I will ensure that there are reinforcements for timekeeping, which will be a reward and a penalty (Eyler, 2002). This will be a crucial timekeeping strategy where all tasks are expected to be completed on time without unreasonable delay.
All these time-managing strategies will be applied as stipulated by the guidelines in the experimentation stage. It will be crucial that all the team members understand the rules and regulations relating to time management so that they do not complain when penalized. I will ensure the process is proactive so that the team may have a reflective learning process of time management (Lynch et al., 2021). As the team leader, I will lead by example by ensuring that I follow all the regulations for time management.
In the concentrated experience stage, there will be a need to encourage the team member to react to the time management strategies. I will develop time data management questionnaires where team members may fill the reacting to the team strategies on time. I will also apply behavior psychology theories to understand the members’ reactions to time management strategies. Time management has always been an emotive issue in any team because some members will always come late or do not meet their deadlines (Eyler, 2002). Therefore, I must show other members that keeping time and meeting deadlines is less stressful.
I will ensure that I have drawn critical information from the collected data in the reflective observation stage. The questionnaire is a crucial tool to assess whether the time management strategies rea working and whether the deadline and timekeeping are met. Other sources for reflective observation are interpersonal conversations on issues relating to time. Using all the information, I will better understand whether I have learned something from my time management techniques (Eyler, 2002). I will assess which strategy is working and which needs improvement or discarded.
My reflection on this challenge is that time is a finite resource that can fail a software company. Launching the software that had only been tested for a couple of weeks was risky. However, the team, especially Khalid, was able to pull through. I felt I could capture and transfer the tacit knowledge through reflective learning (Erichsen et al., 2016). I have found a faster way of learning software development time management strategies.
Conclusion
Software development is a continuous reflective learning process that can only be achieved when teamwork and investment in the best resources. Reflective learning is the best way to understand a software shortcoming and rectify it before the product is launched. The prototype development is a key source for reflective observation data and guides future product adjustments. Without reflective learning and practice, it would not be easy to improve Bright auction’s virtual reality business plan software.
References
Erichsen, J. A., Pedersen, A. L., Steinert, M., & Welo, T. (2016). Learning in product development: Proposed industry experiment using reflective prototyping. Procedia CIRP, 50, 454-459. DOI:
Eyler, J. (2002). Reflection: Linking service and learning—Linking students and communities. Journal of social issues, 58(3), 517-534.
Daniëls, E., Hondeghem, A., & Heystek, J. (2020). Exploring the outcomes of group reflective learning for school leaders. Reflective Practice, 21(5), 604-618.DOI: 10.1080/14623943.2020.1784865
Fridge, E., & Bagui, S. (2016). Impact of automated software testing tools on reflective thinking and student performance in introductory computer science programming classes. International Journal of Information and Communication Technology Education, 12(1), 22-37.
Lynch, M., Kamovich, U., Longva, K. K., & Steinert, M. (2021). Combining technology and entrepreneurial education through design thinking: Students’ reflections on the learning process.Technological Forecasting and Social Change, 164, 119689.