I bumped into a fairly interesting customer case a while back. One of our customers started a joint software development project with a number of other organisations. The aim was to develop a system that would combine the expertise of all of the participating organisations and improve communication between them. Naturally, this meant that all of the organisations developed one part of the whole project in their own sub-projects.
Sure enough, all of the participating organisations' core business was something else than software development. The actual software development was outsourced to third party vendors, who had to be included in the project as well. Our customer acted as the coordinating party of the whole project and thus needed to solve some major infrastructure related problems.
More players, more problems
Since all of the organisations were creating one part of the final outcome of this giant project, their communication and collaboration needed to be seamless. Hence, everybody who participated in the project needed to see and understand what was going on in the other sub-projects. So, in the technical sense, the development environment had to be transparent and easy to use.
Traditionally, these organisations had just relied on their vendors, who had managed the environments, hosted source codes, managed documentation and whatnot. But in this case this was not an option: multiple different organisations with multiple vendors would have resulted in a pandemonium of separate environments, and no living soul would have had any kind of understanding of the project as a whole.
As a result, there could be only one development environment and it had to be managed by our customer, who coordinated the whole project. Since they were not experienced in this kind of activity, the workflows had to be well designed, and they needed to be able of delegating responsibility to other organisations as well.
Who does what?
The main problem in this particular case boiled down to managing the access rights. I.e., who gets to see what, and who is responsible for granting the needed rights. Because there was a lot of different organisations with their vendors, our customer couldn't possibly know all the needed access permissions and set up all of the projects and tools. So, managing the access rights had to be delegated somehow.
As was mentioned above, all of the participating organisations, including our customer, had their own part of the whole project to develop. To make things a bit more complicated, the participating organisations had to be able of accessing all of the sub-projects but the vendors' access had to be restricted to only the projects, in which they were involved in. The participating organisations needed to be sure that their business-critical information was not leaked to wrong people.
In a case like this, where you have to combine multiple organisations, vendors, and projects, you end up juggling with hundreds of user accounts. Because the coordinating organisation wasn't able of managing the access permissions in all of the sub-projects, the access management had to be delegated to the project managers of the sub-projects. These project managers consisted of employees of the participating organisations and few key personnel from their vendors. To keep the rest of the vendors' developers from roaming free in the whole development environment, different type of account was introduced.
To solve all of these requirements, we created a so called Layered Access Management (LAM) model in collaboration with the customer. LAM is a three-level access management model: the highest layer consists of the Company Admins, under the Company Admins, we have User level, and under the User level, there is so called Collaborator level, whose access is restricted to only the project, in which they are invited in.
What comes to workflow, we decided that a few of our customer's (coordinating party's) project managers act as Company Admins, who then grant User permissions to the rest of the organisations' project managers. In addition, 1-2 key persons from each vendor were added as Users, so that the vendors didn't have to ask the project managers to do tasks that should be done by the vendors.
Now, the Users were able of setting up their own development projects to Deveo and inviting the external stakeholders as collaborators to the respective project environments. In other words, the actual access management and project creation were delegated to the User level from the Company Admins. This meant that those people who had the best knowledge of the needed rights were able of granting access to all of the right people. Since the participating organisations were not software development organisations, they lacked the needed know-how of setting up the repositories and integrations. That is why few of the vendors' key people were granted the User rights.
To make this model tick, Deveo was introduced as the central platform for the development. A dedicated Deveo Company for the whole project was created to Deveo's cloud environment, in which all of the participating organisations and their vendors worked on in their own separate projects. The separate project environments for the sub-projects were set up by the project managers (this blog post shows how easily that is done), who also managed the access permissions in their own projects. The above mentioned key people from the vendors then acted as the main users from the vendors' side, meaning that they set up the repositories and integrations, and added the rest of the external developers as Collaborators, whose access were restricted to only the projects in which they were involved with.
If you want to see this in action, check out this video below. It demonstrates how Deveo's layered access management works in practice:
In a very complicated cross-organisational project that consists of multiple sub-projects, it is utmost important to choose the right development tools. However, creating a common environment with all of the necessary tools is not enough, if you don't have an effective and secure way to handle the access rights.
In this particular case, our customer needed a simple, yet powerful development environment, which they could manage themselves, but could also delegate most of the actual access management. Deveo's delegated access management and self-service approach was the key to a successful project despite the delicate balance between transparency, delegation, and restricted access permissions.
How have you solved the access management problems in complex projects? Please share your thoughts on social media!