A few weeks ago Don Kim put up a blog post challenging the value of certifications. I reached out to Don in hopes of doing an interview about it and found out he’s also written a new book “I think Therefore I Plan”. In this interview we discuss the pros and cons of different certifications, taking an artisan approach to managing projects as well as Don’s new book.
You can find Don’s book here: http://amzn.to/2n7VEHu
You can find Don’s blog post about certifications here: http://bit.ly/2okDUZA
00:07 Interview Start
00:30 What is a Human APEE
03:38 What is an Artisan approach to Project Management
05:15 Don’s Philosophy of Project Management
07:22 Trying to slow down and do less
08:21 Don explains his way of approaching project work and the reason for the book
10:56 How has the traditional vs. Agile debate changed over the past few years
12:53 Seeing the value in every project you work on - regardless of how you got it
16:15 The downside of certifications
17:29 The positive aspects of certifications
18:03 There is more to project management training than just PMP certification
19:48 Making the case for the value certifications can provide and how it can be misunderstood
23:22 Does it make sense for people to want to have a way of gauging their professional achievement?
23:55 What Don expected from PMP certification and how he went deep with the Kerzner to get the most learning out of it (instead of just passing the test)
26:41 Is it the certification that is an issue, or the way people interpret it as an end point rather than a beginning
27:50 An overview of the approach Don’s book takes towards the art of Project Management
30:56 Where you can find Don’s book and how you can reach him with follow up questions
31:54 Podcast Ends
Day 1 of the inaugural Digital PM Summit is in the books and it was impressive. The event is being held in Philadelphia and is billed as "The first conference for a community of people who manage all things digital". I've attended and spoken at a lot of IT and PM related conferences in the past and there is definitely something unique going on here. There are a lot of conferences that focus on design and a lot that focus on development, and what they offer covers a wide range of subject matter and are delivered in a variety of formats. There are also a lot of PM conferences that focus on project management from the more formalized approach to managing work. And there are the Agile conferences which cut a slice across those areas. However, those conferences don't really speak to the audience that is present here in Philly this week. For the folks who manage projects at digital agencies, there is a different need. The agencies tend to be small to medium sized businesses with projects that can last anywhere from a month to a year (on average). The teams tend to be smaller in nature and many of them are caught in a space where a "just do it" can work for awhile, but it brings a lot of the pains you'd expect (stress, marathon last minute efforts, and technical debt). They could go the route of moving towards a more formal approach (like PMI), but the process burden doesn't really fit with the needs of the client or the work culture. They could also address a lot of their challenges with Agile, but this is not an ideal fit for many of their clients who are often more traditional minded and aren't compelled to change. So, what they end up with are a need to be able to manage work using a variety of approaches based on the needs of each specific project and client. At a larger organization (upwards of 50), it might be possible to bear the overhead of staff who are expert in different areas and approaches, but most of these organizations have a more lean approach that requires them to be able to develop a broader range of options in how they manage work. Coupled with that is the fact that the medium they work in is in a constant state of flux and they are expected to always be on the edge of what is the new, best way of designing things that leverage the latest tech.
The PMs in this space have to have one eye on design (maybe one and a half) and the other eye on technical practices. And somewhere in the middle, they still need to develop PM skills. Going back 10-20 years, my experience in this space was that the project management side of things involved a lot of floundering around, establishing a new approach every time things went really side-ways. The agencies that garnered all the attention back in the boom were places like Razorfish that kept a keen eye on the design side of the medium. That was, and remains, a valid approach, but this field has grown and evolved and is hungry for a better way. Unfortunately, none of the primary options can holistically solve the challenges they face.
What I have found to be truly unique about this event is the programming and the attendees. The way yesterday began offers a great example of what I believe makes this event a valuable and interesting alternative. The day started with Jeffrey Zeldman giving a talk that was rooted in design and UX standards. It was followed by Jared Ponchot that also skewed towards design as well, but dealt a lot with the creative process and how to approach creative work. The third speaker was the Conference Chair, Brett Harned, who gave talk called "How to be a Better Project Manager". Each of these talks would be at home in a variety of separate conferences, but putting programming like that together for this sold out event is what set the tone. These are not PMs who want/need to spend an hour learning about a better way to do Earned Value or, Critical Chain or managing projects that deal with Sarbanes-Oxley, CMM, ISO or (insert process here). These are design centric PMs who are deeply involved in the creative process who, while they may not self-identify as servant leaders need an approach that enables and supports their creative and technical leaders. Agile has a place here, but these folks are not Agilists. Traditional practices have a place here, but these folks are not PMPs (mostly). They are also not (mostly) designers or developers. They are creative PMs in the digital space. While it would be great to be able to develop expertise in each individual area (design, development, traditional PM and Agile), the years of work that could take would definitely be at odds with the realities of serving their clients.
One of the things I found most impressive yesterday morning was that for during the first 3 talks, there was the level of attentiveness and engagement of the people present at the conference. That is not to say that people who attend other conferences aren't engaged and attentive, but this was different. My experience has been that at a traditional PM event, career PMs look for a few new ideas and go to validate what they think they know. At an event like Øredev, technically savvy knowledge workers who are more on the advanced end of the spectrum go to be challenged with new ideas and ways of working that are often a few years ahead of the curve. At an Agile Conference or Scrum Gathering practitioners of Agile get together to work on how to get better at applying Agile. What I saw yesterday was a room full of people who were all there to find better ways to help the work that are fully respectful and supportive of the creative and technical process. They were not so much looking for ways to change how others work, but more for ways to change how they approach their own work.
Five or ten years ago, I'm not sure if something like this would have sold out so quickly to an audience that includes attendees from all over the US and some from Europe as well. But this community of Digital PMs is a segment of the PM community is definitely hungry for the opportunity to share and hone their unique spin on the field of project management.
Kudos to Greg Hoy, Brett Harned, Allison Harshbarger and the folks at Happy Cog for having the vision to create this event and for having done such a great job with it. #bigdamnheroes
Ten minutes ago I was supposed to be writing this blog post. What I was doing instead was cleaning out the articles I have stored in Instapaper that have been in the queue for so long that they are no longer worth reading. This seemed really important at the time. And, I was actually-really supposed to be writing this blog post 30 minutes ago. But 30 minutes ago I was doing the stuff I meant to do 2 hours ago. And that is because 2 hours ago, I was still asleep because I stayed up until 3 AM trying to finish the things I had planned for the yesterday. This morning is all about the productivity hangover.
Yesterday, like most days, I planned too much into the day. There was no realistic way I’d be able to get it done given the fact that time is not quite as flexible as I’d like it to be and that I don’t have one of those boxes from Primer.
When a problem comes along...
In working through this Personal Kanban project there is a question thing that has remained kind of an open issue for me the entire time. What about WIP? If you aren’t familiar with it, WIP stands for Work in Progress. In Kanban, the goal is to limit your work in progress in order to help maximize your throughput. Or, to put it more simply, you need to understand how much you can do at once before you start mucking things up. Once you understand that, you need to prevent yourself from taking on too much at once (and mucking things up). This also helps you understand how long it takes to get items through the system.
For the most part, the practitioners of Personal Kanban that I have spoken with have admitted that WIP is not something they pay much attention to. In speaking with them I did not dig too deeply on that topic at the time because it seemed to be non-critical. I was looking at WIP as a holdover from a more traditional approach to Kanban that had less relevance in Personal Kanban. Also, whether or not it is right or wrong, the items on my board are not sized in any way. Everything is the same, whether it is a writing a new Statement of Work, doing a load of laundry, finishing Clive Davis’s biography, or going through the legal steps of closing down a company. It is all just stuff I am trying to prioritize and do.
If you can dodge a wrench…
A few weeks ago I started working with an Agile Coach who was willing to take on the role of being my Personal Kanban Coach/Sherpa/Confessor. I am very fortunate that he was willing to take this on. The guy is brilliant and I have mad respect for him. I also can’t help but feel a bit bad for the guy. As far as being a coachee goes, I’m definitely having much with the room for optimization.
When I told him I told him I wasn’t really tracking my WIP I am pretty sure I heard him fall off his chair. The productivity guilt monster reared up and shamed me… so I recanted. I explained that I was tracking WIP …-ish. Which meant I had listed a number for WIP at the top of each of my columns and then I just wildly ignored that whenever the hell it seemed convenient…. Which was/is most of the time.
Putting the “fun” back in dysfunction
Shockingly, there are days when I can’t get everything done. Many times the reason is that I have other activities scheduled during time I would otherwise be working. I feel safe in the assumption that I am not alone in this. And yet for many of us, we somehow manage a level of delusion that permits us to plan to do work during the time we know we will be otherwise engaged. When this happens, we have these items, which we unrealistically planned, which cannot be completed on the schedule we put together. I have a master’s degree in project management and I’m deep with the Agile. I know how I am supposed to do this. I also know that how I am doing this is not healthy. I know it is not realistic. And yet it happens, over and over. I’m slowly becoming even more aware of how sharply fundamental an issue this is and how deeply and negatively it impacts my productivity. Because I do not have a clear and present awareness of my capacity and how to plan for that without exceeding it, I am always overfilling my bucket. When I am teaching people in a work setting about how to keep from doing this, it’s easy to explain. I even have a calculator I’ve made for folks to use to help prevent them from overcommitting themselves each Sprint. But on an individual level am I really supposed to size every single thing I do and plan for doing just that and no more? That’s just not realistic.
And suddenly, just like that, I’m one of “those” students. The ones who like the ideas behind Agile, but who really need to spend some time at the Wall of Won’t.
(The teacher in me would now like to take the student in me out back now for a quick kneecapping… just for good measure.)
Sadly, I do not have a card for that on my board.
I hate when that happens.
Sherman! Time for a new Experiment!
I believe that understanding my capacity at a daily level, and planning to meet, but not exceed that capacity will allow me to complete more work each day. I believe that getting more items to a done state each day, and not leaving a lot of unfinished work on the board will have a positive impact on my ability to get work done that will further improve my productivity. I also believe that if I do not plan to do more than is possible in a day I will be better enabled to get the rest I need to be as productive as possible in future day. This is all common sense. It’s been proven over and over. We all have that voice in our heads telling us that we are special, that we can do more, that we are not bound by the normal laws of time and physics.
Yeah… not so much.
To experiment with this I am going to run two tests. First, I’m going to try the easy one … estimating ideal time for the items in my list and then also estimate my capacity. It will involve some overhead because I am going to have to do this every day, but I will try it for a week to see what happens.
The second part, which will be more challenging for me will be to try breaking my work up into pieces that are small enough to track progress on a daily basis. I’m going to run this for two weeks and then report on it.
Next week I’ll be back to the topic of software for Personal Kanban.
Off the Rails...
Categories: Agile, Agile, Agile, Agile, Agile, Agile, kanban, kanban, personal kanban, personal kanban, personal kanban, personal productivity, personal productivity, personal productivity, productivity, productivity, productivity, productivity, project management, project manaqement, project planning
It was all going so very well. By the start of the 3rd week I was beginning to get the hang of the process. I wasn’t a shining model of productivity, but I was certainly making improvements. I was learning a lot about how I worked and what I needed to do to become more productive. I had started making notes about all the experiments I wanted to run in the coming weeks. I was keeping my PK Journal up to date. The only issue was that I hadn’t tried it with real work yet because I was also still on staycation. (I travel a lot for work, so when it comes to vacation, I’m totally happy to just spend the time at home becoming fully present with what a bad decision it was for someone who is horribly allergic to cats to adopt three of them.) Being at home for the first part of this experiment had allowed me to establish the physical habits of personal kanban and my hope was that this would keep me rooted in the practice once I was on the road again.
So naturally, the obvious next step was to completely screw that all up.
I had planned to be away on a retreat for a few days during the 3rd week. While I was there I picked up a slight cold that immediately turned me into a walker for about 8 days. Both of these events meant that for a period of almost 2 weeks, I was completely unable to do work on anything on my board.
So… time for a Failure Bow
(If you aren't familiar with the Failure Bow, I'd like to recommend watching the Matt Smith TED talk below.)
While it would be easy to rip myself up for losing step, I knew that was going to happen at some point. What I was more interested in was what it would take for me to recover when it did happen.
Since I’d been keeping detailed notes on what was and was not working I turned to those to try and see what issues were causing the biggest trouble.
“Hi, My name is Dave… and I’m a Things-aholic.”