Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Aerospace and Defense, Agile, Strategy
Transforming Project Management Style From Traditional Waterfall to Agile
Can anyone provide an example of developing a complex electro/mechanical product (a complete automotive system, engine, interior, braking system, or appliances, refrigerator, oven, etc...) using the agile methodology instead of the traditional waterfall approach? I have seen IT developments of PCBs, wire harnesses, software, but never a full finished product.
Sort By:
Ann -

There is no agile methodology, rather one could use an adaptive life cycle or specific adaptive techniques when managing a project.

For complex physical products where there are significant regulatory requirements and "real world" constraints on iteration, adaptive approaches tend to be used during the R&D or prototyping phases of new product development, but once a set of features have been defined and a design finalized, the delivery will usually follow more of a predictive approach.

Agile does incorporate lean principles and those can certainly be applied to such projects.

However, for the software components of the product, those could certainly be produced using a more adaptive approach.

Kiron

Kiron
Automotive parts sometimes fit quite well with agile, especially those developed in a racing environment. A racecar becomes the test bed for systems (brakes, engine, aero, driver interface, etc.).

System level example: The brake calipers may be developed using CNC (changes can be made via SW) before the final production part becomes a casting where tooling changes can be cost prohibitive. Electronics are laid out in a larger format (easier to do when you have no passenger seat) for easier replacement and things like ABS may be changed via software.

The race season format allows for incremental (albeit sometimes very expensive) changes from race to race as the car is developed. Data acquisition systems monitor both individual system performance, and overall vehicle KPIs. At each race, value is achieved both for the race team renting track time to drivers, and the sponsors developing technology.

There are many ways this approach can be used in industry. Some systems like primary structure may be very poorly suited for iteration, but if you get a bit clever, a lot of mechanical and electrical systems can be developed using agile principles in the right development model.
I working for Chrysler when the "genesis" of XP. Then I worked for Ford Motors, PSA/Peugeot in charge to implement Lean and Agile. If you as me, the shift is mainly in minds of the project manager, no matter it is not usually writing in the PMI documents for example. But is not because you use Agile. Is because any type of approach you use. Here comes my personal experience and what I talked in conferences: -Focus is on solution, not in project. -Trust is the key. You have to trust into each people that works in the project. -Monitoring is more to work close to theory of constraints than "traditional" scheduling management. I mean, if you think that things will happened exactly in the time/moment stated in the schedule you are lost. I can write much more here but in fact take a look to theory of constraints (TOC). -Reports has to be adjust to your process.
If terminology gives you a challenge, consider just calling it Lean Engineering/Lean Manufacturing. It may be easier for people to embrace lean vs agile... The two are in fact cousins... and share many of the same principles and some of the practices. In any case - focus on delivering the most value/highest quality and eliminate waste... and it won't matter what you call it.
Read "Eight Years to the Moon" the history of the vision to put a man on the moon and return to Earth. At that time, we had 15 minutes of sub-orbital flight experience. The final system delivered was the Most complex combination of systems ever assembled and the process to deliver it incrementally had begun in 1958, with failures and success to "educate and adapt" on the least understood set of requirements, in the history of man. Adaptive practices and those engaged in performing them, was used long before the term "agile" was every used to describe a mindset of progressive elaboration and delivery. I have a second example from a project completed in 1932, using the same JIT techniques and adaptive techniques to build the Empire State Building. Finally, in 1968, a record that still stands today, was created by H.B Zachary to build and deliver a 22 story hotel in 9 months, for a project that had no funding, design or resources, or prepared land, when the project started. It still stands today and is the Hilton Palacio Del Rio, in Downtown San Antonio, Texas. Let me know if you would like more details or discuss the of any of these examples, the information is all out there and I promise it will amaze and encourage you, on your journey.

Agile value should be measured by Continuous Learning and Value Delivered, for as long as the system has a life cycle. I measure personal success on the same two attributes. Are you learning and is your value to your stakeholders, always improving? If the answer to either is no, your system is dying a slow death.

Bonus, there are Youtube videos to help you gain insight into these projects. I have the books and the experience, through years of study and practice on similar efforts of a smaller scale, with higher impact to the stakeholders.

Best wishes always,
I had the same question as Ann , but about construction sector.
You can always mix the 2 approaches within your project management style. The bigger question and where the difficulty lies is the adoption of the methods of Agile within your organization. If the team, and better yet the Management, doesn't understand or get your process, it's like pushing a wet noodle up a hill. But don't let that stop you. Educate others. Show them data. Show them proof that it will work.

Break some of the work into sprints and deliver product/engineering reviews on a regular schedule.

Use tools that show an Agile flavor. Kanban boards, sprint reviews, etc.. Get your stakeholders involved in the process and get that feedback right back to the team for implementation. Explain why change is good, and better, early in the process rather than at a launch.

Get creative and maybe you can make some simple changes that bring a great, positive impact to your organization.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Man will occasionally stumble over the truth, but most times he will pick himself up and carry on."

- Winston Churchill

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events