Agile or Traditional Project Management – Which is better?
In project management circles, we hear a lot about agile. Agile is an iterative, incremental method of managing the design and build activities of engineering, systems, etc.
Recently, I ran across a firm that didn’t use an agile approach to ERP implementation – is this good or bad? Who is to say?
Related Article: Agile Project Manager – Traditional PM Triangle be Damned! Keep Quality First!
There are some specific agile methods, and there are agile components to managing a project. From that point-of-view, although agile can gain results, I don’t see that the purist approach is necessarily better. On the other hand, I have seen many project successes without the use of agile. In my experience, using the common sense aspects of agile makes good sense. Beyond that, it can lose its value.
When it comes to ERP implementations, I have a strong bias to using the common sense aspects of agile, mainly because my focus is on results. Here are some of the main features that have proven effective:
1. Additive approach to the design: What could be more geared towards common sense? This frequently occurs with ERP projects. Getting the optimal design is one of the most important key components to success. Even with the most experienced process design and applications resources working together, I’ve yet to run across a project that could design everything in upfront. Similar to research and development, there could be 10 solutions to one problem. They will have different advantages and disadvantages. The only way to test these out with the users to figure out what will work most effectively in supporting the business is to use an iterative design.
For example, a building products client is in an ERP implementation process. In this industry, the use of configuration is common. Although using a configurator makes the process easy for the order fulfillment process (which is why it can provide a competitive advantage), it is far from simple behind the scenes. There are many scenarios and variables to think through. Starting with the base design and testing it through provides a meaningful, reasonable chunk that folks can wrap their mind around. Then with a common sense agile method, additional complexity and layers can be added down-the-line. On the other hand, every potential impact would have to be thought through upfront without this iterative approach. There is quite a lot of pressure on this approach – with a much lower success rate.
2. Root cause analysis: As designs are tested with a common sense agile approach, the idea is that there is just enough design completed to see whether the process is working; however, there isn’t “too much” complete so that you can’t figure out the root causes of issues that arise. If there is one thing that is a certainty, it’s that issues will arise – there will be speed bumps along the way. Undoubtedly, you’ll be able to figure out the root cause if you work on it long enough; however, it is a much simpler process if you limit the variables up front. Start with just those variables that are most essential to your project. Then, as bottlenecks arise, you’ll be more successful in determining and resolving the root cause.
3. Flexibility: Last but not least, in today’s Amazon-impacted world, customer expectations frequently change, company priorities are diverted, and global conditions evolve. Thus, flexibility is paramount to success. In our experience over the last several years, over 80% of projects have changed along the way. If the project team wasn’t flexible, they struggled, and results were slow. On the other hand, we have been able to speed up customer lead times, product development cycles and month-end closing routines by maintaining our flexibility. Certainly, there is no downside to maintaining flexibility.
For example, on a significant project to improve service levels, we planned for forecasted sales levels. We were successful in winning a big customer contract. Instead of going deeper into past due, we were able to support this customer contract since we had built flexibility into the system. We were able to move cross-trained resources to where they were needed the most. We were able to bring on a team of temporary employees for those areas that required less skill. We were able to ramp up with suppliers because we had provided them with advance notice of the potential and partnered with them to increase output.
Although traditional project management gains results, using a bit of agile common sense can provide two critical factors in the current business climate – speed and flexibility. There is no downside in pursuing it so long as you use common sense and adjust accordingly!
[…] Information on that Topic: projecttimes.com/articles/agile-or-traditional-project-management-which-is-better/ […]