+++ Agile IT Project Management at OEMs & Suppliers +++ The Trends, Challenges & Risks of Agile Change +++ Methods of Solution for Agile IT Project Management +++
OEMs and suppliers continue in their relentless progress towards agility. In the past few years, even large companies have ventured to try agile methods, preferably in software development. Agile IT project management is the trend!
This article gives an overview as well as tips on the below topics:Read article in German
Special Download: Agile, Traditional or Hybrid Project Management? (PDF file)
Please fill in the form.
* Required Fields | Data Protection
The Different Conceptions of Agility
Top management decides to introduce agile practices such as Scrum, Kanban or DevOps. They commission a governance department to design company-specific models for these methods and provide the necessary staff training. External consultants are likely to be involved in this. After a few months, the concept is in place and the employees have undergone comprehensive training.
Yet, in what way can we impart the method and especially the mindset to the organization to create a common understanding? How do you integrate external partners who may have adapted the theoretical models differently? And how do you motivate employees who have been using different methods for decades and are skeptical of changes?
With almost every project start, we are still facing exactly these challenges. The customer’s project managers are renamed Scrum Masters, the stakeholders from the department now go by the name of Product Owner, yet they have not undergone training. And external consulting companies are commissioned for pure development services according to Scrum methodology. Meetings are quickly created, and the first Sprint begins.
Yet, the User Stories are often too unspecific or the Definition-of-Done (DoD) and Definition-of-Ready criteria too generic. In distinct cases, this state continues across several Sprints – after all something needs to be presented to the department – and there is little time to clarify fundamental issues. At this point, an agile understanding at project level alone will not be sufficient.
If company philosophy or culture are contrary to agile values, the change of culture will be difficult to achieve (see Management 1.0 vs. Management 3.0 et al.).
Yet, this is precisely the time which is essential for project success: overall conditions and responsibilities should be discussed and determined upfront – by the entire project team at least. The cultural change still needs to be driven by the entire company, with top management leading the way.
Another interesting read: How to reduce resource conflicts with agile planning
A common understanding of how to approach the project is the basis for future collaboration.
- On what level are the project participants?
- Do processes have to be altered due to lack of expertise or availability?
- How can the project team compensate for this in one place or another?
You do not necessarily have to follow a purely agile approach. Hybrid methods are often more promising, as the participants tend to find the orientation a little easier. As long as there is readiness among the project participants, team and role coaching can lead to a significant improvement in collaboration across the project duration.
Product Vision and Roadmap
“We work with agile methods, so we don’t need a plan!”
Many of you will have heard this sentence here and there. Yet, agility is not to be mistaken with chaos. It is true that visible increments can be presented faster with an iterative approach and changes can be added to a product sooner, but in the end the product should provide added value to the user. Without a product vision and a clear roadmap indicating which goals should be achieved at what point, it is easy to get lost in the details. At the same time, the various requirements of the stakeholders will become overwhelming.
Without a clear goal in mind, it is easier to stray off track. Therefore, everyone on the team should be familiar with the long-term vision as well as the next intermediate goal. Knowing why you are doing something is a great motivator and helps you stay focused.
As Dan Pink describes in his successful book Drive – The Surprising Truth About What Motivates Us the Purpose is one of the three most important motivation factors in today’s working environment.
Clear goal setting at the project or product start including a roadmap or the creation of a rough milestone plan helps increase the added value of the product and support the Product Owners in their role. The constant comparison of the current product with the product vision helps to better prioritize the Product Backlog and makes discussions with stakeholders easier. In cases of doubt, the actual function of a product will not be greatly improved by placing a blue button in the top right corner or a green button in the bottom left. Do not needlessly waste valuable time and capacity with this kind of issue.
With the aid of methods such as Design Thinking, you will find out the user aspects when creating the vision. You will record these aspects in a Business Model Canvas or for example a Product Vision Board. The Business Model Canvas has the additional advantage that it can be used as a decision paper in the discussion with product sponsors.
Our tip: Let the users verify your vision once it is complete. This helps avoid the risk of losing them.
Agile Fixed Price
The team or even the company have reached a mutual understanding, the product vision is complete and resonates with the entire team. Sounds like it’s time to get started. But that would be leaving out sales and the legal department.
Now you need to turn this project construct into a fixed-price package to be able to get service providers on board. Understandably, companies protect themselves in order to establish comparability between providers and transfer part of the project risk to the service providers. The service to be provided, which is not yet specified, is packaged into mini units.
At worst, you take User Stories which will never be implemented in this way as references. The resulting “fixed-price” units, such as Story Points, User Stories or T-shirts, serve as empty shells for future implementation topics. Before each Sprint, you take a blank size M T-shirt and print a logo (User Story) on it that roughly fits the bill. Only time will tell whether the increments between the T-shirts were appropriate.
This is where the stakeholders’ flexibility and wish to collaborate is in demand. A joint estimate by the whole team will increase understanding on both sides. You should also agree up front what services are covered by a Story Point or a T-shirt.
Openness and transparency within the team work wonders. Pay attention to the following points:
- Will efforts for governance and meetings be assigned to the existing User Stories or will they be charged separately?
- Does the estimate apply to pure development efforts or does it include the detailed design and testing?
- What about the subsequent deployment?
You should also address the approach to potential idle times. If budgets are cut overnight or the department has failed to specify User Stories due to vacation, you run the risk that teams can no longer implement efforts or charge for them.
A second technical backlog containing documentation, technical debt or optimization measures such as refactoring or test automation can prevent idle times and will add value to the product.
An agile comment on the fixed price topic:
Unfortunately, a lot of effort goes into the clarification of pseudo-fixed prices and the tasks of correctly mapping and accounting for this in organizational terms. However, this does not add value to the product that is to be developed. Put together a team commissioned to work full time on the product for the expected project duration. In this case, it is possible to implement a greater number of valuable functional and non-functional requirements at the same risk.
The agility of OEMs and suppliers continues to advance relentlessly. It is practiced in relation to processes, predominantly in IT departments but not only there. The employees have caught on to the idea. Now, the only challenges are to increase the maturity level and especially to work on the agile mindset.
In summary, you could use the following aspects to increase the maturity level, strengthen the mindset and maximize project success.
- Create a consistent understanding (of agility) on the team at the project or product start. This does not necessarily have to be Scrum by the book.
- Make sure you formulate a clear product vision and define a milestone plan. This allows you to check whether your work contributes to the product and helps you keep focused.
- Define an estimation procedure together with the whole team and define the service description of the billable units (Story Points, T-Shirts or User Stories). This enables you to avoid unnecessary discussion during implementation and to build a fixed-price construct including external services.
- Try to reduce idle time through optimization, technical improvement and further training of the team. Thus, you can keep the team on the same utilization level and do not risk the downsizing of a winning team.
Any questions? Just leave a comment below or write to us at firstname.lastname@example.org. We will respond as soon as possible.
Nils Schweizer has been working in the project and service management environment for years since finishing his business degree and B.Sc. He has completed certifications in Prince2, ITIL V3 and PSM1. After getting valuable insights into the OEM world at MAN, BMW and Siemens, he supported Sulzer GmbH in setting up the US subsidiary. Since 2018, he has been directing the company’s project management across all locations.
Find out more about Nils Schweizer on LinkedIn.