PMOs – Think Outside Of The Box. Will Kanban Work For You?

Gaining visibility into the big picture of an IT portfolio feels like one of the unsolvable challenges, and it’s not for lack of trying. Dashboards abound, and PPM tools are becoming more user friendly all the time, but do these tools really provide transparency into what’s really going on? Sometimes I think these tools provide MORE information than what you need, akin to telling you how to build the watch when all you want is the time. After reading Dave West’s “Why Kanban Matters,” I think more and more about how Kanban will provide project management offices with the information they need so that it can feed the portfolio more efficiently.


At a glance, the PMO knows where everything is in its cycle, what’s in the pipeline, and a brief status of what is important or in the need to know. Depending on the information that bubbles up in the brief status line, the PMO can determine where there may be resource constraints or where demand is driving the next steps . . . and it enables executives to get a visual of how demand is affecting current projects and supports the PMO’s need to communicate status without flooding dashboards with useless information. This can drive valuable conversations based on clear, concise information — it’s hard to miss what on tap and what is being delayed. It’s a process whose time has come.

Have you thought about leveraging Kanban above the project level? I’d love to hear your comments.


To-do list vs Kanban board

Where Kanban is great is at multi-step step processes, when to-do lists just don't work well anymore. Kanban helps you detect the bottlenecks.
In IT, for example, it works well for issue/bug tracking, since those involve multiple stages, with developers resolving the issues, testers testing them and managers approving the work for release.

We use smartQ ( online Kanban board and it has even the option to limit different roles till what stages they can move a ticket/story. Which makes it very easy to split the functions of the team. Plus the custom fields let us capture any extra information.

But Kanban should not be limited with IT. It can be used anywhere there is a multi-step process and a high volume of repeating tickets. Call center is a good place to look into.

Transparency Into IT

Hi Margo,

Thanks for the article. I think the general principle is absolutely correct. However, I think that you're pointing to PMO process as a way of knowing where everything exists in such processes is actually open to gaps in data and transparency. Any good IT leader knows that most PMOs cannot manage everything that goes on within an enterprise and, as a result, usually PMOs usually tend to limit themselves to monitoring bigger Programs and Projects, rather than smaller day-to-day delivery of solutions, such as those that are a part of Budget Pools, Break Fix or Business As Usual activities. As a result, many new IT solutions or modifications to existing IT solutions make it through delivery pipelines and out into Production Operating Environments, as part of day-to-day activities, under the disguise of Break Fix or Business as Usual funding and "never" make it onto the PMO process radar. (This is far more common than you'd think.) However, if an IT organization is doing its job properly, all Software and Systems, big or small in nature, "always" go through some aspect of an enterprise's Systems Development Life Cycle (or SDLC). (NOTE: Software folks might replace "Systems" with "Software" in the SDLC but they're fundamentally the same concepts.) The SDLC is the more accurate delivery "Assembly Line" to monitor because, big or small, all systems tend to go through an SDLC.

Here's something to consider... IT must have an SDLC, in order to be successful, but can survive without a PMO and its processes. The reverse, however, is not true. The proof, very simply, are smaller companies that deliver many IT solutions but who are too small to have PMOs. PMOs are typically a symptom of enterprise size. SDLCs are not and must always exist.

SDLC phases or steps are more clearly tied to actual delivery activities than those of a PMO's processes and, as mentioned above, everything must go through an SDLC but not always through the PMO. Therefore, using the PMO's processes as a baseline can cause severe gaps in data, metrics, and "transparency" for those Systems that do not go through the PMO. This implies that it's an IT organization's "SDLC" and not a PMO's set of processes that have more accurate transparency as to what is actually being delivered or supported, throughout an enterprise.

I would recommend that you consider replacing your PMO specific columns or silos with those of a standardized SDLC, which are more accurately aligned with the key strategy, planning, design, manufacturing, quality assurance, delivery and support steps that most, if not all, IT organizations follow. You can use any proper SDLC. A simple example is the IF4IT's SDLC, which is highlighted in the IF4IT's IT Learning Framework.

Given that Kanban was specifically derived for Manufacturing and Delivery and that SDLC is also tied to such concepts, while PMO processes rarely are, I personally believe that applying Kanban to SDLC makes far more sense.

Anyhow, I hope this makes sense.

My Best,

Frank Guerino
The International Foundation for Information Technology (IF4IT)

kanban beyond the project level


I am currently trying to apply kaban at the program level for a client. The client manages a "pool" of developers who work across 3 types of projects new dev, enhancement and maintenance. We are trying to use Kanban to solve a couple of problems:

Manage internal customer expectations through WIP and Class of service
A view of resources usage across projects
Possibly improve the verall process.