I've been talking to a variety of potential clients about their project portfolios. One of the big problems is how to see all the work. Some of these folks have multiple kinds of projects, so they want to show their work in a variety of ways.
What do you do when you have a few big projects and a ton of small projects, such as several clients of mine have? I have an IT client and a couple of R&D clients with this problem. I'll take an R&D client as an example.
They have big projects that they want to show in a calendar-like fashion so their management can see how the majority of their time is spent, just as in the image to the left. In this case, the project rank is implicit. And, they have many small projects that come into their group by email, by conversation, by randomness.
I suggested they need to visualize the work, so someone can rank the work. One of these clients is an engineering firm, who has a electrical engineering group, a software group, and a mechanical engineering group. We think a kanban board is a good first step, so this is what we set up.
This board would be great if they had someone to rank the backlog. They don't right now. The people who keep asking R&D to do these small projects are all over the organization: Sales, Marketing, Support, Senior management, Training. There is no one person who is willing to take on the role of ranking the backlog.
These folks are not alone. The good news is that more and more people are coming to me, wanting help with their project portfolios. The bad news is that their organizations are not yet willing to make the strategic decisions about which projects to do and not do.
Visualizing the work is a necessary first step. Once you see that there is more work than an Engineering or R&D group can do, you see the need to make the decisions. Then you can ask the zeroth question, “Should we do this project all?” If the answer is yes, go ask the qualitative questions and quantitative questions.
If you don't collect the work, you can't see the work. If you can't see the work, you can't rank the work. You can't make good project portfolio decisions if you don't collect the work.
BTW, my participants at the workshop in Sao Paulo will be the first to hear everything about how to integrate the two kinds of boards, calendar and kanban in their organizations. I bet you wish you would be there…
Here is a promotion of the work I did last year that was all about visualizing the portfolio. (I may have taken the picture.)
http://pinnacle-strategies.com/blog/2012/08/visual-project-management/
And notice for all of you folks who want tools, that Jack and his folks started with stickies. Gotta start with stickies or cards, because that’s how you stimulate the discussions.
Absolutely agree that starting with post its, whiteboards, and flip charts is ideal. However, what’s the next step? I’m working in a large enterprise that wants to make work visible, though the scale and logistics will require a tool. And from what I’m seeing, it’s mostly coming up as an unfilled need. Ideally something that would support impact mapping, story mapping, and task boards. Something that would enable Kanban at all levels, and have those entities tied together through relationships. Thoughts?
Kevin, do you want to see all of those items at the same level? That’s looking at the roadmap and the project portfolio. I have a todo this week to post my new pics of kanban boards. That might help.
In the meantime, have you seen We Need Planning; Do We Need Estimation? See the images there for what an agile roadmap might look like.
No, no, not at one level; that would be madness! 🙂
My ideal tool would enable drag and drop relationships with virtual post-its into any relationship configuration needed.
It would also represent strategic down to task level work, and have those levels of abstraction roll up and down into each other.
Target Process actually is quite a lovely tool; it’s hitting the sweet spot for us more than any other tools I’ve seen, and having used it heavily for several years I can say it really does the job quite well; there’s just not the same flexibility as with analog boards.
And yes, I LOVED your posts on estimation and have referred to them often. I’ve found most agilists completely unwilling to give up on story points and velocity; guess I’ve gotten Kanban in my blood now!
Kevin, I do understand your desire to move things around at different levels, and see how the strategic creates the tactical.
I also use TargetProcess. I use it for my work as an editor for agileconnection.com. We see the state of the articles and have a chance of organizing by theme if we want. (I almost never want that, though. I like a variety of articles for different people.)
It’s a quandary for me, about the board vs. the tool. With a board, you see the work you’re not doing. The work you don’t do is invisible in a tool. I see the need for tools. I also wonder how we see the work we are not going to do. As I said, it’s a quandary for me.
Great post!
I find this time and time again to be a huge source of problems between the business and the development organization. Often the development organization becomes a whipping post and even allows itself to be put into this position by not pushing back and forcing the business to make portfolio decisions.
Visualizing the backlog is a huge first step to help the business realize it is their responsibility to negotiate and make trade offs, not the development organization. It is interesting to see the changes that happen once the business no longer throws things over the wall and have to make rational decisions about where to invest development capabilities.
Thank you again for the reply; I appreciate how responsive you are to questions and comments. ::sigh:: yes, I think this is the quandry we are all in as we attempt to scale knowledge work to the enterprise level. With physical work, such as manufacturing the work is inherently visible, whether it is work to do or work needing to be done.
What we’re beginning to experiment with is using Target Process to print out cards (it does this beautifully; click the Actions button) and set up physical boards at the team level. To begin we’ll rely on the teams to manage their boards, and simply write on the cards when they move states. On a daily or weekly basis, we’ll collect the cards from their done column and enter the data into the tool. Target Process is very cool in that it allows you to back and forward date entities. With the data entered, we can visualize progress at the higher levels, both to understand how work is moving through the system and also to begin planning future work.
Of course none of this replaces managers practicing Gemba to better understand what and how work is being done. One reason I’m loving Target Process for this is that it is explicitly not a tool to manage people allocation or highly precise time tracking (though it can be used to some degree for the latter). We’re fortunate that executive management truly wants to help attain a sustainable pace and stop people from being overworked.
Anyhow, I’ll keep you in the loop as we progess, if you’re interested 🙂
Kevin, that is so cool! Yes, please keep (all of us) in the loop.
For those of you who are wondering, Gemba is the way an observer can see a process and see what to improve. It’s much like management by walking around. In Behind Closed Doors, Esther and I renamed this to Management by Walking Around and Listening.
I’m really fast to respond when I’m in my office. I’m slow when I’m not 🙂
Pingback: Blog AdaptWorks » Blog Archive » Por que devo aprender Gestão de Portfólio com a Johanna Rothman?
Portfolio transparency (“what’s in it”) is really a key enabler for the organization to understand the amount of parallel work and the work queuing up. I’ve recently shown a Cumulative Flow Diagram of several of product lines with lead time analysis etc.
My experiences on what I call “Business Kanban” apply Kanban method to the fullest on business-level and it has been suprising how fitting the concept is on more abstract level of work.
More about it here on my blog:
http://improvementstory.net/2012/08/25/business-kanban/
I totally agree that visualization is a way to go when it comes to project portfolio. It seems a natural next step to adopt kanban board to deal with project portfolio. However, it becomes more and more tricky, as projects have different mechanics than work items — they aren’t updated that often, it is difficult to name specific stages, etc.
I actually documented my story with project portfolio kanban here (http://blog.brodzinski.com/2011/11/project-portfolio-kanban.html). It includes a standard kanban board design and goes further — to a complete redesign of the board.
Pawel, in _Manage Your Project Portfolio_, I discuss how to do this for projects, not just for the small projects that drive people crazy. My experience is still that many organizations need a calendar view of expected project duration, even if that is total fiction.