Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Why you should use Kanban for project management

public://pictures/Fotograf 1 IMG_7807.jpg
Annette Vendelbo Director, Xvoto ApS
 

IT projects are by definition complex, and being an IT project manager (PM) is a multifaceted and advanced role to fill. You manage teams, budgets, contracts, plans, and the risks that may hit you. You must keep your managers and stakeholders satisfied, and you likely manage sub-contractors as well.

To structure these diverse tasks, most companies have implemented a PM method (PMM) of some sort. Many are inspired by PMI, PRINCE2, IPMA, and others. But why do we still see so many projects failing? For the past 10 years, PMI has issued its annual “Pulse of the Profession” report, which typically shows that only around half of the projects we start are completed within time and budget. And its latest report (February 2016) reveals even more discouraging trends: Projects failed more often in 2015 compared with 2014. 

This article will provide what will be for many readers an introduction to Kanban, an agile method that is rising in popularity, and which addresses the complexities of IT projects in a unique, visual way. 

Agility led so many to Scrum, but...

With heavyweight, process-centric PMMs, there is more emphasis on delivering to the requirement specification than delivering the quality and value needed. With Scrum, which emerged in the 1990s, the pendulum swung in the agile direction. The focus became very team-centric, and the PM was taken out of the project equation. At least in theory. Scrum works with a defined set of roles, events, and artifacts, and a new vocabulary was prescribed.

However, Scrum has not been the solution to all project problems. Elements that influence the success or failure of Scrum projects include:

  • Company maturity and level of agile understanding
  • Team maturity and competencies
  • Allocation of team members to multiple projects
  • Effective product ownership
  • Acceptance of transparency and visualization

The reality is that the prerequisites for a good Scrum are not always met. Agile teams work in non-agile organizations, and teams do not understand the DNA of Scrum and what it implies concerning team behavior. Scrum's product owner role is often not filled effectively, and not everyone likes transparency. That is, some feel intimidated by everyone knowing what everybody else is doing, and by open discussions of productivity and progress.

Furthermore, Scrum is difficult to use in organizations with a strong control-and-command culture. It is also a huge challenge to scale Scrum to the program and portfolio level. How should you handle risks, dependencies, interfaces, etc., between multiple Scrum teams working on one product? While Scrum works well on smaller software projects, it does not fit as well on the program or portfolio level.

To cut a long story short, neither traditional waterfall methods nor Scrum have given us the project results that we strive for. Both offer solutions to some challenges, but not all.

How Kanban makes the lives of project managers easier

When I came across Kanban, I realized that it might provide what I was looking for. One reason is that Kanban respects an organization's current roles, titles, hierarchies, etc., and starts the improvement journey from there. Kanban is as much a mind-set as a method.

Getting into the details of the Kanban method is beyond the scope of this article. But one thing makes perfect sense from a PM perspective: With Kanban, you are always working on the most important activities first, as quickly as you can. This behavior evolves from the six core Kanban practices:

  1. Visualize your work
  2. Limit work in progress
  3. Manage flow
  4. Make policies explicit
  5. Implement feedback loops
  6. Improve collaboratively, evolve experimentally

There are some similarities with Scrum—for example, visualization and feedback loops—but the work approach is different. With Kanban, you handle different types of work in one board, and you focus on flow and completing tasks:

“Stop starting—start finishing.”

This is what projects really need, as it prevents tasks from being 90, 95, 98 percent complete for ages. Best of all, you get rid of your project plans, activity lists, and Excel sheets.

Kanban captures and measures all types of work

I have tried but found it very difficult to plan my PM/project work in sprints. But with Kanban, I can capture and measure all various types of work. This typically includes:

  • Technical work
  • Repetitive PM work (e.g., meetings, status and risk reporting)
  • Work with deadlines
  • Subcontractors’ work
  • Unexpected work

While it makes sense to limit work in progress (WiP) on work within our control, it doesn’t on subcontractor work. I do, however, visualize subcontractor deadlines and follow up rigorously. Thus, you get a holistic view of your project as it is visualized on the Kanban board. It also brings value to visualize and measure work that was previously invisible—i.e., "unexpected work." I measure how much time it consumes and the cost associated.

It is, in fact, possible to work this way in all types of organizations, provided you're allowed to do so. This is what's involved in managing projects with Kanban:

  • A big white board, colored sticky notes, and magnets
  • Managing expectations with your steering committee (if you have one)
  • Explain:
    • how simplified project reporting will still keep them in control
    • how simple metrics show them trends, undesirable variances, and progress
    • how visualization shows them the true project status at any given time
  • Agreeing with your team on how to work with Kanban (no, Kanban is not just a big task board)
  • Agreeing to the working principle “Stop starting—start finishing”
  • Showing predictability and stability (comes automatically once the above 4 points are in place)

Does Kanban solve all your project challenges?

No, Kanban isn't going to solve all your problems. But the answer to poor project performance in the past has been to add more control mechanisms, bureaucracy, processes, and complexity to the PMMs, and that has only made them more difficult to use. Moreover, organizations involved in complex projects find it difficult to understand their role in the project ecosystem. 

There will always be decisions, dilemmas, and complexity that no method can fix. But for me, Kanban has definitely made my life as a PM easier, and it has resulted in higher success rates on my projects.

Image credit: Flickr

Keep learning

Read more articles about: App Dev & TestingAgile