OK, so I landed in this fine, fine job, leading a crowd (almost 150 actually) engineers who work on, well, software projects. Not a surprise, eh? With such a big team your job is mostly orchestrating things. You just have to keep the machine running and performing well.
What you basically need is an overview of stuff. All kinds of stuff. For me personally the easiest part of catching up was people. Well, of course no matter how hard you try you won't have the same relations with 100+ team as you had with 25 or, heaven forbid, 5 people. No surprise here, it was totally different from that neat tiny team I had previously. Anyway learning who I work with was sort of easy.
However to make any reasonable decisions in such team you need to know, at least on the high level, who does what and how exactly you define different "whats." I mean, you need to know all the ongoing projects their importance, relationships with clients, experience needed to successfully complete specific types of projects, and so on and so forth. In short: you need to learn hell lot of things about dozens projects.
And you better be quick as the first person knocking to your door to ask for people for a specific project is coming next week. Early next week. Namely Monday 9 am.
OK, first days, well, first months you spend in a fog. That's natural. Then you start to actually know what all these teams do on a general level. Except you keep forgetting all these details: when this project starts, when another ends, how many man hours/weeks/months/years we plan for the other and which of those two are somehow connected with the other one you've just discussed.
It was exactly this sort of situation I found myself in. I could have started a rugged friendship with our budgeting application but it isn't a friendship you dream of, if you know what I mean.
On the other hand I knew Kanban enough to play with it in completely different area and I heard there are folks applying it on portfolio level successfully. Sounded like a perfect idea for an experiment.
To be honest I didn't make a deep research on the subject. The basic concept is simple if you already know Kanban – you treat projects the same as you treated features and then the magic happens. Well, I might be oversimplifying a bit, but only a bit.
After all I tackled the problem with a proper mindset: "what I start with is wrong so I will be changing my approach as I learn what works and what not."
My expectations were simple: visualization would help me to have control over what is happening. At the beginning I didn't even set any goals how I wanted to adjust our project portfolio. I just wanted to start and see the early results. Knowing Kanban for a longer time I felt pretty sure there's something good waiting for me on the way.
Finally, I accepted the possibility that I would eventually abandon portfolio level Kanban if it doesn't give me any value. So that's how it all started.
In the next post in the series you I will share what the first version of my portfolio level Kanban board was.
Project Portfolio Kanban Story is the place where the whole series will be aggregated once further chapters are published so keep an eye on it.
WordPress.com
