The development project manager (dpm) encounters a variety of challenges on a daily basis, from working closely with the client to schedule releases and timelines, to reporting regularly to the steering committee, to day-to-day work with the development team and technical discussions with the solution architect – and don't forget to coordinate fully with the total project manager.
Work as planned with agility
Today, Scrum is deeply rooted in the hearts of the people, and most people are at least familiar with agile teams and working methods. This is especially true in software development. Young developers rarely embrace concepts such as timelines, deadlines, and waterfall models. Development is rarely a linear process: unexpected stumbling blocks and constant rearrangements are considered normal. It's the world that gave birth to agile working methods, and it's the ones that are most used in the field today.
things get so exciting when the world of agile work is combined with the needs of long-established automotive engine manufacturers, who still value qualities like careful planning and adherence to deadlines. it project managers working for automakers are well aware that management needs a well-designed timeline. most decision makers don't like to resign themselves to their fate, which is why this timeline must cover everything from start to finish, from receiving demand and supervising production to delivering software. so it's not surprising that manufacturers expect companies that are entrusted with developing software to exhibit these qualities as well.
development project managers: bridging the gap
both agile work and traditional project management have their advantages. long-term software development projects cannot work without one of them. that's why it's crucial to have colleagues who are at ease in both worlds and build bridges between the two. this is one of the key skills of dpm. they strike a balance between the client's desire for structure and careful planning with the reality of the development process and its often unpredictable nature.
set the scenario: logistics control development project
this case study was a project in which one of our clients was commissioned to replace the existing logistics control system with a more modern logistics control system. since the existing software contains many different solutions for the end customer, the standard software that has not been tuned can only meet some of the necessary requirements.
The process of adapting existing software to meet the specific needs of the end customer will be complex and time-consuming. the situation becomes even more challenging due to delays in project launch, and the fact that some developers are working on other projects at the same time. since our client did not have sufficient capacity to manage their largest development project in several years, they entrusted dürr consulting to take over the management of the development project.
good for you
we bridge the gap between agile work and traditional project management – and can work equally effectively in both systems.
proven project management office services: we always pay close attention to time, quality and cost.
long-term project experience in automotive engineering and general manufacturing
organize and communicate more than programming
we've explored how dpm can facilitate the relationship between agile and traditional project management. now let's take a look at what dpm actually does. their primary responsibility is to organize and communicate; while the goal is to produce software that works properly as a final product, dpm is generally not involved in programming. their work focuses on collecting and organizing large amounts of information, adapting it to the needs of their target audience, and sharing and discussing it with relevant stakeholders. in a typical week, the dpm of this development project will organize and lead the following meetings with different stakeholders (as shown in the image below).
daily meetings with the core employees of the development department (called samples). the purpose of the 15-minute day meeting is to examine the progress made and the obstacles faced by each person, and to address any obstacles that cannot be solved within the development team.
weekly internal management meetings. in addition to providing an update on current development work, the purpose of these meetings is to agree on measures to help overcome obstacles that cannot be resolved within the development team.
With the customer's Miles fixes. Regular communication with the end customer is an important foundation for any successful development project. That's why the people involved in the project organize a regular meeting.
The conference was attended by DPM, general project managers and project managers on the end-customer side. They will discuss all issues related to the planned implementation of the project. This includes release timelines and timelines, as well as current technical challenges.
There is also a Two Weekly SteelCo Project Meeting, attended by project managers and senior management representatives from both companies. The main purpose of the meeting is to provide an update on the status of the current project, but it is also an escalation and decision-making committee.
while less structured, the relationship between the dpm and the development team leader is also critical: they must work closely together and be honest with each other. the development leader knows his team very well and can provide the necessary resources in a short period of time if needed.
timelines for complex software projects
As cicero once said, "plan carefully before you begin". Hower shared the same view. "planning is worthless, but planning is everything". the contrast between traditional project management and agile work is more obvious than project scheduling. the former relies on long-term plans with distinct phases, while the latter prefer short-term plans that react to data in real time. as for how much time it takes to complete an "epic" (agile term, referring to a larger unit of work under a goal), software developers' estimates can vary by a factor of three. by definition, development tasks involve creating something new, and that often means you can't learn from past experiences. therefore, the estimation of time is merely an estimate.
This high level of uncertainty is caused by technical and organizational risks, such as the absence of key employees. another common risk is that software developers often understand the goals differently than they do with their customers.
Anyone involved in software development has probably heard an interesting metaphor: the situation is like a swing that moves back and forth in opposing positions, from the customer's description to the project manager's understanding of its description, to the programmer's work, and finally to the customer's actual needs. this often results in a software product that takes a lot of time and effort to build, but does not realize the added value that the end customer needs. one of the tried-and-true ways to deal with these general uncertainties is to incorporate contingency factors into the schedule in case of unexpected delays. however, in this particular case study, the timeline was set before dürr consulting took over the dpm role.
dynamic, data-based planning
DPM and the head of the customer's software development team agreed on a dynamic, data-based approach to planning. What does this look like in reality?
Our customers are using the "Jira" software for internal operations. This allows you to estimate the duration of development work at the story and/or epic level, and then assign each story to a planned release. It also lets you update the capabilities of your development team.
Jira uses this information to create a dynamic plan in the Gantt chart that clearly shows which phases will be completed in which version based on the latest duration estimate. The actual duration of each story is automatically recorded based on the time recorded by the developer.
If individual phases take more time than originally planned, the schedule is automatically adjusted and the critical path is redefined. If the release date communicated to the customer may not be achievable due to a particularly long delay, it is easy to see in advance. This gives DPM more time to deal with lag situations.
the success of scheduling begins with a requirements engineer
Requirements management of the system is key to ensuring that the functionality of the software created is aligned with the actual needs of the end customer. When first commissioned to Dürr Consulting, in a comprehensive lessons-learned meeting with all stakeholders, it became clear that product owners (POs) had taken on many roles in the past.
The new role of requirements engineer was created in response to the requirements of the conference, with the aim of unleashing the capabilities of more POs to focus on their core responsibilities and introduce a professional requirements management system.
The requirements engineer then developed a methodology to ensure that the requirements were seamlessly integrated into the Jira development environment. Since his role is dedicated to requirements management, he is able to work more closely and deeply with the project manager of the end client. This means that the vast majority of development efforts are actually directly tailored to the needs of the customer. Punctuality and productivity have improved as bug fixes to address misunderstandings about the end goal have been reduced.
software development also requires a clear structure
Leads to the crossover of remittances. Crossover often leads to communication problems and difficulties in defining responsibilities.
That's why Dürr Consulting, together with the development team, has developed a special process, as shown in Figure 2. The diagram depicts the different phases of the software development process (line 1), the associated requirements (2), who is internally responsible for achieving these requirements (3), and what interactions with the customer are required to achieve the goals of the phase (4). The process overview concludes with a flowchart listing related files (5) and a "definition of readiness" (DoR, 6).
No comments:
Post a Comment