How to use Kanban to “Lean” into infrastructure projects in an IT consulting shop

I originally posted this on LinkedIn back in June 2016. I’m reposting here because I’d like it to live here on my own blog. Since the original post 2 years ago I’ve changed companies and changed tools. I’ll write an updated article soon.

Back in February 2015 I took on the role of IT Practice Director in an IT consulting shop, leading a team of engineers in providing infrastructure projects and all-around IT outsourcing services for small/medium businesses. And like most businesses in America (by number), we’re small. We don’t have hundreds, let alone thousands, of employees, so we can’t afford to create highly-specialized positions — we all need to wear a lot of hats. For example, it’s not reasonable for us to employ a full-time Project Manager. We could definitely use that kind of help, but we can’t justify the salary and truthfully we couldn’t keep such a person fully engaged or grow their professional skills. Plus, the extra workload from running our projects in a fully PMP-certified manner would increase the cost of our projects, and our clients wouldn’t appreciate it.


Despite lacking a formal PM, we do IT projects all the time. We migrate clients to Office 365 or other cloud systems. We upgrade servers, storage, virtualization platforms, and networks. We collaborate with outside firms, such as cabling specialists and data center providers like our local favorite, Metro Data Center. More importantly, we often do all those project types simultaneously for multiple clients. In effect, we have our own little PMO (Project Management Office), but there’s no PM calling the shots — just me and some IT engineers.

As you might imagine, it ain’t easy.

The Problem

When you have upwards of 20 projects going simultaneously, usually for just as many clients, simply keeping track of what’s done, not done, and coming up next can make you crazy, not to mention tracking sub-tasks, projected hours, shifting priorities, and the heterogeneous skills of the engineers. Aside from that, we also want to complete our projects so we can… you know… get paid.

Given our situation, we needed a way to solve the following problems:

  • Know what projects (1) are being designed and sold, (2) are starting, (3) are in progress, and (4) are closing or were recently closed, and see all the projects, project phases, clients, and engineers in a unified workflow
  • See where we have resource conflicts so we can design around those situations, but not constrain ourselves to the point where we create gridlock and can’t adjust timelines as priorities shift
  • Display all our work in a visual way that non-engineers can grasp, so we can have meaningful discussions about our work rather than spend most of our time just trying to explain what’s going on to people outside the engineering team
  • Utilize a system biased toward project closure and completion, not sales or project starts (it’s easy to start a project, it’s not easy to finish one)
  • Keep our project management work to a minimum, to save us time and save clients money

We didn’t arrive at our current solution quickly. We went through a few phases along the way, and perhaps what we learned can help your team…

Classic Project Management Solutions (that didn’t work)

To get started with our “lite” project management approach, I turned to everyone’s favorite sortable-text-in-a-grid solution: Microsoft Excel. It’s a great place to get started because you can list everything you’re doing and create more and more cells with various data fields you want to track with each row of data. With automated formatting, you can even color cells and text depending on the contents, making the whole thing easier to grok at a glance.


This went along fine for several revisions and a few months. At one point it jumped from Excel to Google Sheets (to make it shareable and simultaneously editable by the whole team). But the job of maintaining it almost always fell to me. So the more detail we added, the harder it was to maintain.

During this period I also tried using a cloud-hosted project management tool I’d used a few times in the past: Smartsheet. It can be simple or complex, it can be private or shared, and it has nice Gantt-style visualizations as well as dependencies between tasks. It’s Microsoft Project for a fraction of the cost and with a lot more collaborative capabilities.


I ended up using Smartsheet on a big multi-phased project that was hard to manage, but for tracking all our projects it was even harder to manage than Excel. I liked it, but this was a tool that needed at least a part-time PM, and we just didn’t have that available.

By the fall of 2015, project work was picking up and the need to track our tasks individually and as a team was getting urgent. Excel had failed. Smartsheet had failed. Asana didn’t take off, either. And Basecamp, while useful for a lot of collaborative work — we still use it today — just wasn’t designed for multi-project organization and visualization. We were getting bogged down with resource conflicts and project delivery was slowing as the load went up. I needed a new tool, but more importantly, I needed some new methods.

Agile… Scrum… Sprints… Lean…

As an avid reader of IT industry blogs and news, I was well aware of the popularity of current software development methods and buzzwords like Agile and Scrum. I had even introduced the idea of “sprints” during 2015, but lacking other methods, it didn’t take hold. Meanwhile, the literature in the field talking about these new models was focused almost exclusively on software development — which wasn’t really relevant to an infrastructure team.

phoenixprojectI started looking around for books talking about project management using new Agile-ish methods especially in IT infrastructure contexts. I found some books on Amazon, then turned to my Safari Bookshelf subscription to review some of the best examples in detail. That’s when I found The Phoenix Project.

While Phoenix was not a how-to book, I found it a cracking-good read. It’s a (nerdy) novel telling the story of how a DevOps model of work was brought into a fictional corporation’s IT department, and how that transformed (and saved) the business. It rang true to my career experience and it thematically addressed the problems we were experiencing.

Welcome to Kanban

Featured at the center of Phoenix was the application of Kanban, a decades-old Japanese manufacturing operations model, and the theory of constraints. These mental and operational models revitalized the fictional company’s IT function that was mired in competing demands and resource conflicts. I knew I needed to take this to the next step: learn more about Kanban and try out some tools.

I downloaded a few more books via Safari and looked them over, but the turning point was finding a succinct how-to manual from LeanKit: Kanban Roadmap (free via sign-up). The Roadmap explained how to get Kanban started with your team, including terminology, processes, etc. With the Roadmap in hand, I ordered lots of Post-It notes, a big whiteboard, and spent several hours creating project/task sticky notes from our projects spreadsheet.

Our first Kanban board looked like this:


The new board mapped out our project steps from left to right, covering all our major phases:

  1. Sales opportunities (once they exited from Microsoft Dynamics CRM)
  2. Sales engineering and proposal development
  3. Sales completion
  4. Project preparation, setup, scheduling
  5. Project delivery: Work in Process (WIP)
  6. Project wrap-up and closure

Each sticky note was a project for a client. Colors designated project types. Flags were attached to projects when an engineer was assigned.

We then proceeded to hold weekly stand-up meetings at the board and track project movement, discuss roadblocks, rearrange sticky notes as needed, and more. We didn’t use the daily stand-up recommended for software teams, mostly because the engineers weren’t consistently in the office and it felt like too much of a commitment.

Stuff We Learned

Visualizing all the work and making it “public” in the company was a wild ride at first, and we learned things about our unwritten processes:

  • It became clear Sales and Engineering didn’t see eye-to-eye when it came to whether something was “sold” or not (which is typical). We also didn’t always agree on when developing a formal quote was necessary. After a lot of conversation, we set new standards for each phase of the sales process, and that sped up sales qualification and our quoting.
  • Many projects routinely got stuck in various ways. Some stall-outs were self-inflicted, but a lot were caused by schedules and preferences of clients. We could now “see” when projects got stuck, which allowed us to apply appropriate force to “unstick” them. We couldn’t stop the detours, but we definitely shortened them.
  • We struggled too hard to move projects from “sold” to “started” because we lacked a standard process for kicking off projects and setting dates. We were pleased when a sale was made, but didn’t immediately schedule the work because we were still “busy” delivering previously-sold projects. Seeing this let us shrink the gap between “sold” and “delivered”.
  • Executives and sales folks could now easily see what was on the board at any time. Honestly, everyone was shocked at how many clients, projects, engineers, and other activities were in flight at one time. The Kanban visualization gave us shared context and, despite the flurry of sticky notes, we calmed down individually and as a team. We were finally in control.
  • Kanban is definitely biased toward project completion. At every step, we were collectively working to move project “cards” from left to right. A common language developed: “What will it take to move this card to the right?”

Going Digital: Kanban on LeanKit

leankit1While it was fun (it really was!) and even useful to do our Kanban projects board with sticky notes and markers on a whiteboard, we realized this had one huge down-side: you couldn’t see or edit the board if you weren’t standing in front of it. So if you wanted to update something from your desk, or from a client site, or from home… too bad. This made the board less accurate because we really only updated it weekly. It was also a bit of a pain to edit the sticky notes (you often had to make new ones), and if you ever wanted to edit the lanes on the board (which we did a couple times), it was a major undertaking. Clearly, we needed the board to be digital, and ideally in a collaborative cloud service.

I tried out several Kanban-based online tools, but after each trial I kept drifting back to LeanKit, the source of the Kanban Roadmap. LeanKit turned out to be the best option, so I converted our physical board to LeanKit, shared it with the team, and we were off to the races. We still had weekly meetings, but they were faster because the board was updated all week long. Very quickly I also started making adjustments to the lanes on the board — something I’d avoided with the physical board because it was such a pain. But software changes? No problem!

The central part of our board recently looked like this:


We’ve been using LeanKit for several months now, and it’s our go-to project tracker. It’s visual, simple, and shared. It keeps us focused on moving our work forward. We can see where things are working, where work is stuck, when we have conflicts, or when engineers need more work. For us, at our size, but with the complexity of our work and the lack of a dedicated PM, it’s been been a “just right” solution.

One important process change developed recently: we’ve stopped our weekly whole-team meetings. Instead, we do individual engineer meetings on a weekly basis, reviewing status, next steps, and solving problems. The LeanKit board is still visible to everyone, and sometimes project cards jump from engineer to engineer, but we’ve definitely made the review process more personalized.

Up Next: Refine, Repeat

There’s more we could do with LeanKit — there’s a powerful reporting system built-in, and we could load up sub-tasks and sub-boards to break down projects into smaller and smaller bits — but we’ve opted to keep it simple for now. We’re just happy the Excel spreadsheets, Smartsheet plans, Asana to-do lists, and all the rest are gone. We still have too much work to do at any one time, but at least we know the size and shape of the work and we can thoughtfully prioritize better than ever before.

It’s been less than a year with Kanban and LeanKit. No doubt we’ll make more adjustments, and perhaps we’ll try new tools. We may even introduce a daily stand-up, like software teams. But right now, for our team, our clients, and our IT infrastructure projects, we’re doing pretty well.

Got questions? Recommendations? Please drop me a note!