So many folks in the project management profession think that Agile is for software and doesn’t apply to traditional project management but this is NOT THE CASE!!!. Agile is primarily a mindset and a leadership methodology that will benefit EVERY PROJECT!!!!
Agile has many different processes but at its foundation, Agile is predominantly a mindset. Much like “Lean” (which predates Agile but is now considered an Agile methodology), Agile promotes a way of thinking that can be applied to almost every project. Primary aspects of this thought process are frequent customer/user engagement and validation of requirements, and a tenacious drive to deliver value rapidly. There is also a foundational desire to embrace change. Depending on the type of project change is traditionally viewed as more expensive as the project continues which is true, when you have little to no engagement with the customer.
How can Agile be applied to traditional predictive projects?
1) Find pockets of undefined scope where the customer or situation doesn’t allow for early advanced planning. (buckets of Agile)
Traditional project management is built on a large amount of planning for a rather known or defined scope. Once the plan is complete it is executed through a work breakdown structure that flows from one dependency to another tracked through a Gantt chat or other scheduling software that tracks workflows and dependencies. Where Agile can be implemented is in those areas where scope is less defined, and change is expected. Following the agile principle of “make a decision at the last possible moment,” this would allow for the dependency driven activities to progress and possibly add definition to the unknown scope sections. By allowing for Buckets of Agile, you can help the customer through the decision-making process while reducing risk of future change due to re-work or purchasing unnecessary supplies. Applying this concept would also allow projects to start earlier wile certain sections remain undefined.
2) Integrate Agile principle of “stakeholder Engagement”.
Agile methodologies are built around a continual dialog both with the customer and the project team. Ideally, face to face dialog and communication occur daily with the team and you have a biweekly demonstration/touch point with the customer. While this may seem like a potential waste of time it is not. For the customer, it allows the customer to maintain ownership in the project and allows for early identification of desires for change. This may not be applicable for all projects at the “whole project” level but could be applied at sub task levels or could be used on smaller projects. The value in applying stakeholder engagement would be to improve the overall “quality” from the voice of the customer point of view. As the PM, you can see what areas might lend towards change and coach the customer through the potential options for them while the project is ongoing. If you plan in these “buckets of Agile” then there might be a desire for the customer to stay engaged knowing they have creative license in a few areas.
3) Integrating Kanban processes for project teams
For most Agile projects Kanban and backlog are used to manage the overall project. For large scale predictive projects this could be overwhelming. But from a management of daily activities, this concept could be extremely beneficial. While working on a construction project, if my team can see the next two weeks of work in the “backlog” and they can see the priorities of work for today, then they know where to focus, and if there are work delays for uncontrollable reasons, they know where to find “other work” they might be able to work on based on the prioritized backlog on the board. By having this listed then you empower the team to self-organize and participate in the decision-making process.
4) Empower the team to make decisions and solve problems.
This concept is about good leadership as well as project team structure and has many benefits. In predictive projects there can be a fear of allowing decisions to be made at certain levels due to risk or liability. This is understandable to some degree, but by not empowering the team to make decisions, you slow down the ability to adapt to the environment. If you team knows the priorities of work, and they know the intent of the project and the objectives, timelines and goals, and they have clear boundaries in the decision-making process, then they can adapt rapidly to change in the field. This frees up the project manager to focus on future risks or things that may cause disruption rather than day to day operations. Since there is daily interaction with the team, these changes can still be managed. Additionally, if when issues arise, the PM pulls in the team and asks for their feedback on how to solve the problem, the team will learn that they are valued and included which then drives overall team performance. There is a great knowledge base among the collective team than there is with the PM.
In Closing, I think there are many more valuable principles from Agile that will greatly impact traditional predictive projects, but I wanted to get the dialog started. Agile is not a software methodology but a great leadership philosophy to structure and manage projects.
If you want to have a conversation about how this might apply to you and your team, please send me an email.
Josh Atkinson, PMP, DML
Prosci Change Manager
I have experience in logistics projects, process improvement and change management projects, system optimization, heavy rigging and engineered construction, as well as Gov’t consulting and acquisition document development and sustainment.