Above photo shows what is the result of an ongoing effort of every member of the crew. Every single one who has a function on this aircraft has to keep track of more than a dozen different types of documents. If only one document is invalid or expired, this crew member has to stay on the ground. In the project below, we managed to make document management a lot easier for them using SharePoint.
Description and Setup
My two favourite tech-savvy pilot instructors have addressed an issue to me in late July 2021. They described to me their hassle to manage all the different documents and files of the aircrew. To set the picture right, there are more than thirteen different types of documents. From proof of having finished your military sea and land survival, over training reports to medical status reports. They were involved in procuring a software from a really big aviation company. For whatever reason, though the software did not come through. They both were hoping I could craft a good interim solution.
The project scope was really intense and highly limited. Having only August, September, and October to build the solution, the schedule was tight. What complicated the issue were again the usual stakeholders with different interests: IT, Security, and our GDPR compliance officer. As well, I had to design the system in such a way that several hundred people could work in it and find their way – with varying degrees of SharePoint experience. Apart from that, the system had to provide several statistics. At a glance the instructors and planners want to see who is ready for a flight and who is not. Lastly, I should set it up in such a way that I would be out of the loop in the future.
Actions and Outcome
Paramount to this project was to get the users involved and collect requirements. For that end, I put into practice all my knowledge as a professional Scrum Product Owner. This meant, that we decided for sprints of two weeks. During a sprint, I refined future user requirements and implemented the current goals. At the end of each sprint, we sat together in a Sprint Review and discussed the new increment.
Actually, in this project, the sprints have not delivered increments but fully operational prototypes. To realise what the stakeholders wanted, there had been a couple of combinations possible. Every possible combination lead to a prototype of its own. Every prototype in turn had its own advantages – and disadvantages. Because describing the options up front was in this case really abstract, the prototypes helped the stakeholders to come up with a better decision.
After two months, we had finally found a prototype which we wanted to implement. What has helped during all the process is that I had created highly detailed documentation about every step. Unlike software development where you have a git repository and hopefully a good abstraction to describe the problem in code, SharePoint has no such option. I thus tried to capture every option I set and every button I clicked in all the prototypes. To speed things up, I merely took many screenshots of all the different steps.
At the end, we delivered the application on time and even could add some extra features. What is left to do for the user is now uploading several hundred files, maybe even several thousands. Once this has been done, I will give a short update on the outcome of the project.
My Personal Lesson Learned
At one point during this project, it seemed like the main users wanted to not use capabilities of SharePoint I found highly valuable. I persisted and explained these features during every Sprint Review. However, only through prototypes and really implementing and showcasing the features I found valuable, the users could see the value, too. So, I learned that what people do not see (better: interact with), users cannot evaluate. In short, my personal lesson is that I will not talk about features any more, but instead show it to them. Only then, I let the user decide if he/she wants to keep the new features.
As an example: the stakeholders did not want to have sophisticated views. I told them that I was for example able to create a view that shows if any document has to be renewed due to expiration. They first found this feature not interesting. They said they do not need such a summar. When I showed them then a prototypical view, the were excited. Why? They realized I was not talking about a single user but all users. For me, the latter was obvious. So obvious, I forgot to mention this. And, of course, the value of a view for only one user is zero. For all users, it becomes a game changer.