Development Project Management: Bridging the gap between two worlds

Development project managers (DPMs) encounter a wide variety of daily challenges, from scheduling releases and timelines in close collaboration with the customer and reporting regularly to the Steering Committee, to dailies with the development team and technical discussions with the solution architect – and not forgetting comprehensive coordination with the general project manager.

Nowadays, scrum has become well-established, and most people are at least familiar with agile teams and working methods. This is particularly true in software development. Young developers rarely embrace concepts such as timelines, deadlines and waterfall models. Development is seldom a linear process: unexpected stumbling blocks and constant rescheduling are considered par for the course. It was this world that gave birth to agile working methods, and it is this sector where they are nowadays used the most.

Things get really exciting when the world of agile working comes together with the demands of well-established automotive manufacturers, who still value qualities such as careful planning and keeping to deadlines. IT project managers working for automobile manufacturers are well aware that the manage- ment requires a well-conceived schedule. Most decisionmakers are not fond of playing it by ear, which is why this schedule must cover everything from start to finish, from receiving the requirements and supervising production to delivering the software. It’s not surprising, then, that manufacturers expect the company commissioned to develop their software to demonstrate these qualities, too.

Both agile working and traditional project management have their strengths. Long-term software development projects can’t function without one or the other. That’s why it’s crucial to have colleagues who are at home in both worlds, bridging the gap between the two. This is one of the key skills of a DPM. They balance the customer’s desire for structure and careful planning with the realities of the development process and its often unpredictable nature.

This case study examines a project in which one of our customers was commissioned to replace an existing logistics control system with a more modern one. Because the existing software contained so many different solutions specific to the end customer, the unadapted standard software met only some of the necessary requirements. The process of adapting the existing software to meet the specific needs of the end customer was going to be highly complex and time-consuming. The situation was made more even more challenging by delays to the start of the project and the fact that some of the developers were working on other projects at the same time. As our customer did not have enough capacity at that time to manage by themselves what was their largest development project in several years, they commissioned Dürr Consulting to take over the development project management.

• We bridge the gap between agile working and traditional project management – and can work just as effectively in both systems
• Tried-and-tested project management office services: we always keep a close eye on time, quality and costs
• Long-standing project experience in automotive engineering and general manufacturing

We have already explored how a DPM has to act as a facilitator between agile and traditional project management. Now let’s look at what a DPM actually does. Their key responsibilities are all about organization and communication; although the aim is to produce functioning software as the end product, the DPM is not generally involved in the programming side. They focus instead on gathering and organizing lots of information, tailoring it to the target audience and sharing and discussing it with the relevant stakeholder. In a typical week, the DPM in this development project would organize and lead the following sessions with the different stakeholders (as illustrated in the image below):

Daily meetings (known as dailies) with the core employees from the development department: The aim of the fifteen- minute dailies was to go over the progress made and obstacles faced by everyone involved and to take up any obstacles that couldn’t be resolved within the development team.

Weekly internal management meetings: In addition to giving an update on the current status of the development work, the aim of these meetings was to agree on measures to help overcome obstacles that couldn’t be resolved within the development team itself.

Jours fixes with the customer: Regular communication with the end customer is an essential basis for any successful development project. That is why those involved in the project organized a jour fixe. This meeting was attended by the DPM, the general project manager and the project manager on the end customer’s side. They would discuss everything that was relevant to implementing the project according to schedule. This included release schedules and timelines as well as current technical challenges.

There was also a project SteerCo meeting every two weeks, attended by the project managers and representatives from higher-level management at both companies. The main purpose of the meeting was to give updates on the current project status, but it also served as an escalation and decision-making committee.

Although it is less structured, the relationship between the DPM and the head of the development team is also crucial: they must work together closely and openly. The head of development knows his team inside out and can supply the necessary resources at short notice if need be.

As Cicero once said, “Before beginning, plan carefully.” Dwight D. Eisenhower was of the same opinion: “Plans are worthless, but planning is everything.” The contrast between traditional project management and agile working is nowhere more marked than in project scheduling. The former relies on long-term schedules with distinct stages, while the latter prefers short-term planning that reacts to data in real time. As for how much time it takes to complete an epic (the agile term for a larger unit of work under one objective), estimates from software developers can vary by a factor of three. By definition, development tasks involve creating something new, and that often means you cannot draw from past experience. Estimates about timings are therefore only ever that – just estimates. This high level of uncertainty is down to both technical risks and organizational risks, such as key employees being absent. Another common risk is that software developers’ understanding of the aim is often different to that of the customer. Anyone involved in software development has probably heard the amusing comparison of this scenario to a swing moving back and forth between opposing positions, from the customer’s description to the project manager’s understanding of their description, to the programmer’s work and finally to what the customer actually needed. This often results in a software product that has taken a great deal of time and energy to produce, but which does not achieve the added value that the end customer needs. A tried-and-tested way of dealing with these general uncertainties is to factor contingency into the schedule in case of unexpected delays. However, in this particular case study, the time line had already been set before Dürr Consulting had taken over the DPM role.

It therefore wasn’t possible to build in more contingency. So, the DPM and the head of the customer’s software development team agreed on a dynamic, data-based approach to planning. What did that look like in reality? Our customer was using the software “Jira” for their internal operations. This allows you to estimate the duration of the development work at story and/or epic level, and to then assign each story to a planned release. It also lets you update the development team’s capacity.

Jira uses this information to create a dynamic plan in a Gantt chart, which gives a clear overview of what stages will be finished by which release, based on the most recent estimate of duration. The actual duration of each story is recorded automatically from the developer’s logged time. If individual stages need more time than initially planned, the schedule adjusts itself automatically and the critical path is redefined. It’s easy to see in advance if the release date communicated to the customer might not be met due to a particularly long delay. This gives the DPM more time to react to the holdup.

Systematic requirements management is key to ensuring that the software functionalities created are consistent with the end customer’s actual demands. During a comprehensive lessons- learned meeting with all stakeholders when Dürr Consulting was first commissioned, it became clear that the product owners (POs) had taken on many roles in the past. The new role of requirements engineer was created in response to the meeting in order to free up more of the POs’ capacity to focus on their core responsibilities and to introduce a professional requirements management system. The requirements engineer then developed a method to ensure seamless integration of the requirements into the Jira development environment. As his role was dedicated specifically to requirements management, he was able to work more closely and in more depth with the end customer’s project managers. This meant that the vast majority of development work was actually tailored directly toward the customer’s needs. As there was less bug-fixing to address misunderstandings about the final aim, punctuality and productivity both increased.

Introducing a new role freed up capacity for the POs, but also led to a crossover of remits. Crossovers can often lead to communication problems and difficulties in defining responsibilities. That’s why Dürr Consulting developed a special process together with the development team, as illustrated in Figure 2. The image describes the different stages of the software development process (row 1), the relevant requirements (2), who is responsible internally for achieving those requirements (3), and what interaction with the customer is needed to achieve the stage aim (4). The process overview is finalized with a flow chart listing the relevant documents (5) and a Definition of Ready (DoR, 6).

This allowed us to ensure greater transparency and identify crossover problems early on. In this process, the DPM was responsible for managing crossovers. This means ensuring that the requirements for the preliminary work carried out in the upstream stage are clearly communicated in advance of each subsequent stage. Once the process had been introduced, the dailies were structured according to the overview and were focused on a particular crossover topic.

The conditions surrounding the project were very challenging. Compared with other projects, the scope, complexity and time pressure were much greater. Our customer’s organization was able to evolve in the face of these new challenges. The starting point for development was the lessons-learned meeting when Dürr Consulting was first commissioned. The results of an open analysis of weak points led to the introduction of the new role of requirements engineer, a well-defined software development process with clear crossovers and a data-based schedule that uses modern tools. Although it took time to put a new process into place, it quickly led to visible improvements. The clear allocation of internal roles allowed the team to work through the process efficiently. The benefits of increased speed and higher (rather than compromised) quality were also clear to the customer, who said in their feed- back that “the last release made huge progress in terms of functionality,” and “it’s obvious that the development team understand what we want to achieve.” For us, this was proof that our efforts to make constant improvements had paid off.

DPMs are crucial to large development projects as they monitor the many internal and external crossovers, but they can't solve every problem. Having intense discussions between everyone involved is no guarantee that the software will be released as planned, but it is essential for finding a constructive way forward as quickly as possible when problems and delays occur. Whether this can be achieved ultimately depends how well external project management is integrated into the customer’s internal processes. In an ideal case, the fact that the project manager is only involved for a limited time shouldn’t be evident in the day-to-day running of the project.