The desire for greater transparency in the context of IT services is increasing in Germany, especially in times of economic recession. Greater transparency in projects represents both a challenge and an opportunity. We present three approaches to promote transparency and to help to improve communication and increase customer participation in project success planning.
The desire for greater transparency.
Too many software projects fail, are too expensive and are delivered too late. This is nothing new and has been known for years.
In recent months, however, we have seen a new development on the German market for IT services, and software development in particular: project budgets are getting smaller, daily rates lower and the pressure on project success higher. In short: the recession has now also arrived where money was rather loose in recent years and where excessive deadlines and budgets were not greeted with joy, but were accepted.
The desire for greater transparency has become widespread. Transparency about project progress, problems and risks. Project managers can no longer afford to overrun a project budget many times over. Reliability is in demand.
Challenge or opportunity? It depends on your perspective.
Even if this initially sounds like a challenge for IT service providers, there are also positive aspects to this development: A customer who wants transparency is usually also genuinely interested in the success of the project and willing to play an active role in it. And that, in turn, is the best thing that can happen to a service provider.
However, if the desire for transparency eventually leads to the customer being involved in all trivial or easily reversible decisions, a project can no longer be carried out efficiently.
So how do you manage the balancing act between the understandable desire for transparency and productive, results-orientated collaboration?
Agile methods such as SCRUM have brought us closer to reviews, prioritised backlogs, transparent project boards and other important tools that are used in most agile software projects. Nevertheless, the question arises: are these tools enough and do they work in every situation?
The need for transparency varies depending on the situation.
We have reviewed our projects in recent months and realised that both the planned project duration and the different project phases have an impact on our customers' need for transparency.
In large transformation and digitalisation initiatives that run for months and years, 2- to 4-weekly reviews are usually the method of choice to show the customer and other stakeholders new features and keep them up to date on the progress of the project. However, a two-month project requires a different approach. Direct, informal communication channels are required here. A decision such as "Should we invest more time in the analysis or are the current findings enough for us to make a decision?" must be made immediately in order to ensure efficient budget utilisation.
We have observed a similar situation in the start-up phases of our projects: Close dialogue and the ability to make decisions quickly are essential. After all, nobody wants to pay for a team that is unable to act because it is waiting for a decision from management.
In software development, start-up phases often have the additional challenge that a lot of groundwork has to be done first: defining software architecture, selecting technologies, setting up infrastructure and processes. All of this is quite difficult to show as a demo in a review. A closer, more thorough exchange is required.
Transparency can be created through different approaches.
In order to fulfill these requirements for more transparency and closer communication, we have identified different approaches that can be divided into the following categories:
Path 1: Asynchronous communication
Example: The developer's diary
We use the developer's diary especially in our shorter projects and often mixed with a decision log. At the end of the working day, it briefly summarises what the team has worked on and which decisions were made and why. If necessary, topics that are currently blocking the team, such as pending decisions, can also be addressed. Ideally, this information is shared via a communication channel that enables uncomplicated feedback, such as Slack or MS Teams. In addition to the customer themselves, recipients of the communication can be the internal developers who are to take over the project in the long term.
A developer's diary - and asynchronous communication in general - is a particularly good way to create transparency if it is complicated to find a date with the customer or the group of recipients is very large.
As is so often the case, it is important for the success of this measure to define clear rules of cooperation, e.g. the time period in which questions are answered in the developer's diary.
Path 2: Synchronous - passive - communication
Example: Customer participation in the daily
The daily is explicitly intended for the exchange between the developers. Strictly interpreted Scrum Masters and Product Owners also participate exclusively in the role of the developer.
At Spaceteams the team coach and product owner are regular participants in the meeting and contribute relevant information. The participation of a customer who is not involved in the implementation (such as the product owner) has been the exception rather than the rule, but is of course conceivable as a means of creating transparency.
However, a few crucial points should be clarified with the customer: The daily is a short meeting with the purpose of an exchange between the developers in order to be able to work purposefully as a team. The customer is therefore a listener in the daily and usually has no active part, e.g. does not ask any questions to the team. Would the customer prefer to play an active role? Then other methods, such as the alignment meeting, are more suitable.
We also recommend implementing a test phase with the customer to test this method. After a week at the latest, there should be mutual feedback on the test phase: Did participation help to create transparency for the customer, or did technical discussions, for example, tend to cause confusion? Did the customer's participation distract the team or was it possible to carry out the daily as usual? Depending on the outcome, a decision can then be made as to whether the customer should continue to participate.
Path 3: Synchronous - active - communication
Example: Regular alignment meeting between customer and team
When time pressure is high, as is often the case in the initial phases of projects or in short projects, the topic of alignment between customer and team is often neglected. However, we have found again and again that it is worth taking the time to hold a meeting at least once a week in order to stay on track.
Which is why we always focus on the following important questions in the alignment meeting:
- What result does the customer expect from the project?
- Are we on the right track?
- Is what we are currently working on really the most important thing?
- Are there any hurdles in the project that the customer needs to clear?
The alignment meeting (similar to the sprint review) is designed to get feedback from the customer quickly - but without fixed sprint cycles and at shorter intervals if necessary.
Have transparency on the radar from day one.
The three measures described are, of course, merely examples of how transparency can be created for the customer in projects. What really fits when and how must be determined according to the individual situation and defined with the customer. And this is exactly what we want to encourage here: Transparency is important and creates trust, which is why we recommend talking to the customer about their transparency needs at the start of a project (and also every now and then over the course of it) and finding a good way to serve them.
And even if it's repetitive: a customer who wants transparency is usually also genuinely interested in the success of the project and willing to play an active part in it. Let's make something of it!
Sources:
https://dieprojektmanager.com/scheitern-von-it-projekten/
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf