May 11, 2017
Agile Project Management for Non-Software Projects: Why and How
Even though the concept of agile project management is usually associated with software development projects, it offers the same value when managing non-software projects.
The amazing thing about agile project management is that while it drives governance and discipline in every phase of the project it can easily handle changes along the way.
Agile project management addresses a big challenge for project managers in finding the right balance of discipline without choking creativity and innovation.
What is Agile?
Agile was specifically developed as a step-by-step approach for software delivery. Thus, agile project management encourages iterative development as opposed to the classic waterfall approach of all or nothing. Agile projects are divided into user stories which deliver distinct pieces of the user functionality and are prioritized and then delivered in iterations.
Since the formalization of the Agile values and principles as the Agile Manifesto in 2001, Agile has become adopted as a standard in many organizations especially in software development. According to the Project Management Institute (PMI), about three-quarters (71%) of organizations report via the Agile methodologies either always or at times.
Most of the areas that Agile methodologies contribute to include project streamlining, improving team collaboration, expediting project deliverables and timely results. Chris Vandersluis has worked in both IT and non-IT project management for over 30 years.
He has also authored the research paper “Apply agile methodology to non-software enterprise projects”, which he presented at PMI® Global Congress 2014. According to Vandersluis, especially when it comes to enterprise projects, the key factor to consider is the depth of change that is brought about in an organization.
A common problem faced is the creation of a comprehensive plan, which can then be used to deploy the entire plan in one go. For this purpose, applying agile thinking to change management projects is an excellent fit.
He further adds that Agile project management helps teams think of a project first in terms of large goals at the strategic level, and then at a tactical level has us think in terms of delivering production-ready results.
The popularity of the Agile frameworks has further been backed by a report by PwC that has cited Agile projects to be 28% more successful than traditional projects.
When working on a project, the best way to ensure that you reach the desired goal is to divide the project into manageable chunks of tasks, create a checklist /success criteria/ acceptance criteria or even a subset of to-do list that defines the completion of the task.
Assign the task to the right resources and then monitor the progress through appropriate reporting, team collaboration and communication throughout the process through formal reviews/meetings and/or real-time feedback on the task.
By breaking up all your Goals/Projects into tasks you are better able to prioritize and manage the project resources more effectively. When done right, these simple steps can result in successful and cost-effective projects with little or no rework.
One of the essential elements of agile projects is the collaboration among team members on a continual basis not limited to the project’s early brainstorming phases.
It is imperative that project resources are able to communicate their concerns, issues, and ideas to the project manager and other related resources in time. Effective and timely communication not only reduces rework but fosters inclusive behaviors resulting in the creative solutions, above all successful projects.
When you have found the right recipe, the right process, the right set of tasks for running your oft-repeated projects, then template it. Templates promote standards across the organization, reduce errors and takes the guesswork out of process/projects that are repeated. Consistency promotes efficiency.
No project is without risk. Not to say that risk cannot be managed, all it takes is understanding your risks and planning around them. Even though every project can have its unique challenges and risks, a few are common across most projects and can be mitigated upfront.
Resource utilization: Resources are probably the most expensive item in your project bill, their effective utilization is imperative to success. Ensure you have a way to assign tasks to individual resources or sub-teams as required and then not only be able to monitor their progress but also be part of the Feedback / Input loop and catch any concerns or issues and take timely action.
Time Recording: Understanding of your project burn rates is crucial, a time recording, submission, approval capability is key to keeping the project books current and your team happy.
Meetings: A point always overlooked and later regretted, minute your project meetings, not everyone has a super memory.
Work Smart: Don’t be a slave to your calendar and task lists, let the software work for you through automated reminders and alerts, freeing you to focus on more productive stuff.
Agile Project Management for Non-Software Projects
Regardless of its adoption rate in software projects, there are ways to implement Agile for non-software projects. In fact, the manifesto holds many elements that can be applicable to non-software and non-tech projects in general with equally optimized results.
In fact, the effectiveness of incorporating Agile for non-IT projects has been manifested in multiple industries. For example, a survey by the LiquidPlanner states that more than one fourth (27.4%) of manufacturing organizations rely solely on Agile, whereas 56.6% rely on “a combination of methodologies.”
If you are a non-software organization and you want to find out if your organization should adopt the Agile methodology for your projects, see the following illustration provided by Ogunnaike and Ray:
Any project that falls beyond the simple zone must use Agile and for projects within the simple zone will gain little or no value using Agile.
And how would you identify if a project is simple or not? By conducting the Agile Readiness Assessments (ARA) for projects. The ARA reviews various parameters to ensure the following key elements:
- How well are the stakeholders aware of their requirements?
- How well are the stakeholders aware of their technology?
- Do the stakeholders have conflicting interests?
- Is there a high risk of failure?
Understanding Agile Values
The values stated in the Agile Manifesto are:
- Individuals and interactions over processes and tools: This refers to the people staying self-organized, owning the work given and allowing them to communicate. This avoids the need for micromanagement.)
- Working software over comprehensive documentation: This means focusing on the outcome and the product in hand instead of only discussing the possibilities and focusing only on documentation. By focus on what is accomplished, teams can understand the good and bad practices.
- Customer collaboration over contract negotiation: Customers need to be involved in all the stages. It is important to understand and cater to their requirements at all times.
- Responding to change over following a plan: Change is inevitable. Teams and organizations need to be prepared to manage change and have plan B in hand. Flexibility is key.
Adoption of Agile Project Management for Non-Software Projects
Dipanjan Munshi, a Senior Process and Quality Consultant at Tata Consultancy Services (TCS) with more than 17 years of IT experience, has defined a five-point agenda that he follows in Agile consultation.
Even though it is not your cookie-cutter solution, it can facilitate the adoption of Agile for non-IT projects and non-software processes. The 5 points are:
- Define ‘Working software’: The term ‘working software’ can be used to symbolize any project deliverable and does not have to be solely software. This may include designing prototypes, cost-benefit analysis or recruiting a new team.
- Define ‘Customer’: The customer can be your product or services customer as well as all the other stakeholders may directly or indirectly impact the initiative. Moreover, selecting the appropriate Product Owner is very important.
- Define ‘Done’: Collaborate the stakeholders, sponsors, and Product Owner to identify what serves as ‘done’ for each story or deliverable. For example, it can be just implementation or implementation plus approval from a certain authority.
- Measure Business Value: Asses the business value of the work involved using defined metrics. These metrics can be used for measuring factors such as risk mitigation factor or total savings.
- Expect the Unexpected: Projects are meant to undergo various changes throughout the project development lifecycle. This can be the project scope, process to carry out an activity or the goals in general. Munshi recommends going for shorter iterations, joint workshops, continuous reviews as well as consistent and transparent communication.
Through real cases, let’s have a look at how you can employ Agile for non-IT projects.
Marney Andes is a Senior Director at Learning and Development for Air Methods, which is an emergency air transport company with approximately 4,500 employees and 2,000 outside medical crew.
Andes and her team were tasked with developing a strategy to create training and education for the organization. According to Andes, initially, the stakeholders and the team were not aware of the time involved in creating all of the training or the projects required.
Andes and her team decided to go the Agile way through prioritized backlogs using a project management tool. Each month, the stakeholders meet to prioritize the backlog through democratic voting. Through a project management tool, the team creates different boards for backlog elements such as training requests or in-process training.
The stakeholder’s requests are coded as green or red code; green symbolizing that the project can be taken on whereas the red signals for it going into the backlog.
The Takeaway: According to the Andes, this Agile practice helps communicate expectations to the business about why and how the things are done. This practice has also helped the group stay in sync while the process remains transparent and redundancies are removed.
Casey Family Programs
Casey Family Programs was founded in 1966 and operates as an organization that focuses entirely on providing, improving and ultimately eliminating the need for foster care. In 2012, Casey Family Programs began working on optimizing each sector of its operations. The key areas that required these changes comprised business processes, skillset enhancement as well as knowledge sharing.
They structured the work into backlogs e.g. family recruitment strategies, engaging resource parents as partners, resource family assessment, aftercare planning, etc. A weekly sprint was set up for completion of each backlog.
By implementing a few of Agile processes, some of the areas the organization saw improvement in encompassed daily check-ins, sharing work, team collaboration, tracking work, feedback sharing, and better change management.
The Takeaway: The case of Casey Family Programs proved that Agile and, in this case, Scrum can be adopted to address challenges while implementing them in accordance with the culture and environment.
William Kammersell is a former Agile coach and currently a Senior Product Manager at CA Technologies. Kammersell hosted an Agile Camp at Return Path for the adoption of Agile through non-tech teams. He explains how the recruiting team at Return Path implemented Agile practices to streamline the process of candidate phone screening.
There was a need for the team to be more flexible while maintaining transparency as the process was not definite. Kammersell introduced the concept of using Kanban boards to the team.
Through these boards, the team would display the tasks assigned on a public board so that other teams and all stakeholders could stay informed. According to Kammersell, with the entire work displayed on a Kanban board, the teams could understand and see the workload for other teams.
The Takeaway: This case study proves that just by introducing a methodology for the teams to display their work openly, it made in-team understanding and communication better.
As per Kammersell, generally, employees and teams do not share information on what tasks are assigned and what they are working on. This makes it difficult to help each other out, ultimately elongating the process.
What is your take on employing Agile for non-software projects? What areas would you highlight can easily adapt to the Agile framework? Let us know in the comments below.
A software that can help in promoting individual accountability, team interaction, encourage review and feedback, helps template repetitive tasks/projects, provides timely reporting, alerts, and reminders can be key to you keeping your sanity.
Experience team collaboration like never before
Manage your team, tasks, projects and more on a single platform. Sign up today, it's free.