Scoping

To make sure you capture all of the stakeholder’s needs, the first step is to identify these stakeholders. There are typically 2 types of stakeholders involved: governance and users.

Governance stakeholders include people that are tasked with monitoring the quality of the project both from a technical and a business perspective. These typically include subject matter experts, the product owners and the project’s sponsor. These people, together with the project manager that was supplied by XAOP, made up the steering group of the project. This group met once every 2 weeks during the project and was responsible for validating requirements, approving delivered features and keeping the project on track.

Users on the other hand include everyone that will be using the product. As this category included a prohibitively large number of people to involve in the project directly, we identified key users from different parts of business. This group was involved in requirements gathering and application testing. We were surprised how many different user profiles were involved in the key users group which stipulated the importance of determining the key users in function of their specific needs.

We organised a kickoff meeting with all the stakeholders (physical meeting as this was still in 2019). Based on a survey that was conducted among users, we presented both the positive and negative aspects of the product that would be replaced in order to spark a discussion on what features were absolutely necessary to retain in the new product. On top of that, we asked what the stakeholders would like to do with the product in the foreseeable future. We deliberately held this meeting in the form of a workshop where all stakeholders were actively involved in voting on features and ideas to get to a rough first version of the requirements during the meeting. A process that was roughly based on the Google Design Sprint. The combination of preparing the stakeholder for this meeting by running a survey and having them actively participate made for a very efficient meeting and a high level of involvement amongst the users. It also gave a good idea of which key users feel passionate about specific use cases which was important to know what users to involve further down the line. We were lucky that the project started before the global pandemic as we think running such a meeting online would prove difficult although options exist. During this meeting the stakeholders envisioned a future of what the application should ideally be. This poses a risk with regards to expectations. At this point there is no formal agreement yet on what the application should be. So, it is important to stipulate that during the meeting and be clear that none of the discussed things should be viewed as promises.

The kickoff meeting lead to a long list of partially prioritised features and points of attention. This was of great value for the project as it was a strong basis for the steering group to create the requirements document and initial backlog.

Development

In order to remain flexible during this large project we chose the agile development process in which we had development cycles (=sprints) of two weeks each. Each cycle consisted of 3 phases and at the end of each cycle a predefined set of features got delivered.

At the start of a development cycle the list of requirements that are not implemented yet (= backlog) is inspected together with the product owners to prioritise the features. Based on this prioritised list the development team picks a number of features that they will implement over the next 2 weeks. The importance of this recurrent exercise should not be underestimated. Large software projects are in no way static in our experience. A few months into the project we realised some of the items in the backlog were no longer high priority or were much more expensive to implement then initially estimated. This allowed us to restructure the backlog in a timely manner.

The second phase is the actual development process in which the developers work on the features. As features are sometimes not as clear to a developer as the project manager thinks and because additional questions sometimes arise during development, it is important that the project manager and a product owner are available for questions. In our experience, and especially when working remotely, it is best to schedule moments on which developers can pose questions to ensure everything is clear to the developers. A popular way of doing this is to have daily stand-up meetings. we noticed that daily is a bit too frequent as we want to avoid interrupting the developers too often. Therefore, we schedule such a meeting 3 times per week at fixed times.

The third phase encompasses the delivery and user testing of the developed features. Delivery is done during a delivery meeting in which the developers demo the features to the steering group and the key users. If the demo is accepted by the steering group and the key users, the features are made available to the key users so they can test them themselves. In order to facilitate this process of regularly delivering features to the key users during the development phase, a continuous deployment process is used. In our case this means that developers directly deploy a feature when they are done developing it. This process is highly automated. It will check the new feature code for consistency and breaking changes. If the feature passes, it becomes available. To ensure the feature meets quality standards, it is made available in a development environment first so it can be manually tested by our QA officer and demoed before making it available to the key users and, later on, in production. This is vital to our development approach as it enables key users to test new features as soon as they are available, enabling them to request changes or additions early on in the development phase. In our experience, having this process in place is particularly beneficial during follow-up projects as it is able to kickstart such project by having an easy way to check and deploy new code, even if developers do not recall how the original code functions exactly.

Expectations management

When managing large-scale projects, you often find yourself juggling expectations of different stakeholders while trying to keep the project on track in terms of time and budget, even when expectations change over time.

The first step in managing expectations is knowing what the expectations are. Usually, people will tell you what they want to be able to do but often people don’t tell you why they want to do it. While a list of things that people want looks great on paper, this might not be the same as what they need. Making sure you also capture the why enables you to better think along with the users and find out their actual needs. A common pitfall is to simply check off a deliverable from the backlog when the users indicate that “it works as expected” without critically critically assessing the work done by your own team. The need for doing this became clear during the project early on when validating the user interface. While the users were happy with the progress and how it got implemented, we realised this was a suboptimal solution because the data they would be working with in real life would be more complex than portrayed in the use cases that were gathered. Even though it would set the project a bit back as the UI would need to be reworked, we proposed an alternative and pointed these issues out. When the stakeholders realised the alternative would indeed be much better in real live, this was added to the next sprint and the results were greatly appreciated.

One example of changing expectations was that during the project, another company-wide campaign set out to move security to the left and incorporate security earlier in the development process. This also included the mandatory use of new tools such as Snyk in the development process. The impact of this on the project was significant as the deployment process needed to be reworked completely, with no examples from other projects available as this was one of the first projects that set out to completely adhere to the new standards. Facing this reality, decisions had to be made in terms of scope and/or timelines. As this system was part of a larger effort to update the data source systems, a delay would push all of this back and as such was no option. This meant the scope needed to be reduced and some features would not be delivered in the first version of the application. This is where the agile approach pays off. Using our prioritised and up to date backlog we asked the steering group and some key users what features they could do without and for which a workaround could work in a first phase. As the users already had hands-on experience with the application, it was easier for them to imagine and suggest workarounds for some features that were on the backlog. Doing so we postponed some features to a follow-up project to keep the timelines realistic.

To sum up

The project we ran with UCB over the course of more than a year was viewed as a success as the end result was user friendly and catered to the user’s specific needs. We believe that is the case because we did not set out to simply fulfil the list of requirements that was gathered at the start of the project. We use methodologies that allow stakeholders to remain in control and able to change the course of the project during the entire development phase. While this way of managing a project is not always easy and sometimes tough decisions need to be made, in our experience it is the best way to create high quality software that is broadly supported by users and stakeholders as they are at the center of this approach.