Shortly after my last post, my website got hacked. At first, it seemed like a minor glitch: Visitors clicking from google would be redirected to a harmless directory site. However, I was rather occupied with significant business travel, while also relocating my family. I simply didn’t have the time to investigate it. Well, it snowballed into a full-blown crisis, and I re-learned some old management lessons along the way:
Lesson 1: Root Cause Analysis. I consult and train and advice people on the “5 whys” technique, but this time it got personal. Here’s why:
The hackers likely got in through an outdated plugin, BECAUSE the plugins were not updated to the latest versions,
BECAUSE my technophile webhost (Dreamhost.com) does not auto-update the latest versions of WordPress blogging software I use,
BECAUSE my technophile webhost is designed for people who are sufficiently on their technical game to do those update themselves, which did not happen,
BECAUSE I did not do those updates,
BECAUSE I am lame.
When YOU are the root cause of operational or project failure, it can be very personal.
Lesson 2: Always have a backup plan. As I was cleaning out all the corrupted files, I inadvertently deleted all my blog photos. Fortunately, Dreamhost has a restore feature that allowed me to recover those files. THEN, when I moved my blog to WordPress, the change in DNS entries caused my emails to get lost. Fortunately, I had alternate emails that people could use to contact me…and…fortunately, those emails were setup for most of my online services. But in reality, my good fortune was made possible by a little backup planning. I chose my webhost based on its multi-restore features, and I chose my emails to be redundant in case I lost access to them.
Lesson 3: Adapt to the changing reality. I’ve been a customer of Dreamhost.com forever, but it’s time for me to move on. If I am the root cause of this failure, then I need to resolve the risk of causing this same thing from happening again. Dreamhost is a web host designed for technical people who know how to “ssh into a bash shell and grep for which files contain strange commands”. That used to be me 10 years ago, but not anymore. As a father of three, business coach, and entrepreneur, I’m not longer the geek-o-phile I used to be. So, I’ve moved my blog over to wordpress.com, where it’s a little bit more automated and idiot-proof.
In the end, management theory only matters when it has impact on the real world. This time around, I have been taking my own medicine. QUESTION: how about you? When have you had to take your own management or leadership advice?
“How much up-front planning should we do? How many people should we hire? How many meetings, documents and procedures do we need?”
No matter what field or what project, we all face the “how much?” questions over and over. To avoid getting bogged down, project managers should heed three golden rules: Just Enough, Just in Time and Just Because. I first heard these from Mike Griffiths, PMP, one of the earliest council members of the PMI Agile Community of Practice, when we were struggling with a lengthy document. After much debate, Mike interrupted with a seminal insight in agile efficiency: “When it comes to documents, I coach my teams to generate just enough, just in time and occasionally just because. I think this document fits the last category. Our client has asked us for this document, and even if we consider it excessive, the project will simply never get launched unless we use it.”
Let’s take a closer look at these three tenets of agile productivity:
GOLDEN RULE NUMBER 1: Just Enough. Only do enough prep or support work to achieve the primary goal of delivering business value. The problem is that we so easily intertwine this work with the bottom-line deliverable weâ€™re paid to generate. With that confusion comes the temptation to do more prep and support work than is necessary or required.
Yes, we need a project roadmap, but rather than spend time building a yearlong plan down to the hourly resource requirements, we’re going to provide just enough detail to communicate a vision to stakeholders.
Yes, our IT staff needs some technical direction, but rather than waiting to architect every layer of every interface of every system up front, we’re going to provide just enough direction to get started.
Yes, we need to pass the certification and accreditation audit. But rather than defensively launching an avalanche of paperwork, we’re going to collaborate with the auditors to deliver just enough documentation to satisfy them.
GOLDEN RULE NUMBER 2: Just in Time. You could be crafting lightweight documents, lightweight architecture and lightweight processes, and still be doing all that lightweight work way too prematurely. Of course we could need that architecture component, but let’s invest the time to implement it only when we know for sure we’ll need it.
Of course we’ll need a detailed action plan for next year’s project phase, but let’s devote time to crafting that detailed plan when we get to that phase.
Of course weâ€™ll need to generate some documentation, but letâ€™s wait until we get the documentation requirements before we waste our time on unnecessary write-ups.
GOLDEN RULE NUMBER 3: Just Because. This is the constraint that keeps us grounded in reality. I know the 40-page template violates “just enough documentation”, but we’re going to use it, just because we won’t get sign-off without it.
I know forecasting the full project cost up-front violates “just-in-time planning,” but we’re going to do it, just because we won’t get funding without it.
I know triple-entering our hours into the timesheet system violates “just enough administration”, but we’re going to do it anyway, just because we won’t get paid if we don’t.
The next time you’re faced with a dilemma over “how much” of something you should do, rely on these three rules to generate an agile response.
[NOTE: This post was originally published as part of my recurring column, “The Agile Project Manager”, printed in PM Network magazine. Other installments and more info can be found here]
I just finished a week of activities at the PMI Leadership Institute Meeting, here in Washington DC. It was an amazing experience that reinforced to me the amazing value of volunteering at PMI.
Leadership Masters Class is “High Class”
My first 3 days were spent participating in the PMI Leadership Institute Masters Class program. This is a year long selective program to build the skills of PMI’s volunteer leaders. This first of three face-to-face sessions featured a bevy of interactive exercises and table discussions, allowing us to dig deep into the leadership question of trust. We also took a personality inventory called Strengths Deployment Inventory (SDI), where I gained some very un-nerving insights into how I respond to conflict.
The program is very focused on facilitating learning through relationships. One of the features was the class broke up into groups of 5 “learning partners”. My learning partner group is committed to building the relationships needed to hold me accountable on my objectives.
One of the more impressive elements of the class was the participation of PMI CEO Greg Balestrero. He explained that his strategy toÂ support and grow it’s half-million constituents includes aÂ focused investment into its 10,000 volunteer leaders. For him, leadership has become a critical strategic competency at PMI. Greg is a very busy man, with a very busy schedule. So, when he spends a morning with a group of 30 volunteers, it means he believes what he says.
In truth, I came to this kickoff event with some initial concerns. Some of my colleagues had heard and experienced mixed results with this PMI program. But I can honestly say I walked away very pleased, having become a more self-aware leader after only the first part of the program.
A New Direction for the PMI Agile Community
I spent a significant amount of time with Mike Cottmeyer, Brian Bozzuto, and Dennis Stevens planning the 2011 direction for the PMI Agile Community of Practice. Indeed, we skippedÂ several sessions and instead had talked through the whole agile PM space, what our members are looking for, and how we can really promote the discipline of Agile PM. Here are some of the key outcomes from that discussion:
- Mike Cottmeyer will be the new Chair of the Agile Community of Practice. For 2011, the roster of our community leadership council will remain unchanged. I will continue to serve on the council along with Dennis, Brian, Ainsley Nies, Bob Tarne, and Mike Griffiths. However, MIke has generously agreed to take the chairmainship for 2011, allowing me a bit of a break. Also, 2011 will be the year we host our first community elections, and transition the community leadership to a new batch of members.
- We have an operational plan in place.Â Yes, many of us are skilled agile practitioners, but our distributed virtual setup really prevented the kind of self-organization we tried to foster last year.ï»¿ This week, weÂ realized on many fronts, that our community volunteers need much more detail around what needs to be done, and how to do it. So, here is the plan to address that:
- 2010 Q4 – The council will do the homework of (a) identifying the key initiatives for 2011, (b) generating the detailed acceptance criteria for each initiative, and (c) researching the how-to-instructions for implementing those initiatives
- 2011 Q1 thru Q4 – Then, we will complete the handoff to more and more volunteers to implement those initiatives on a quarterly basis during 2011.
- This year is going to be BIG for PMI Agile. During the week, we had the chance to talk with the staff at PMI headquarters about the Agile community and Agile PM in general. Already I’m seeing signs at the Congress of PMI’s growing investment in the promotion of agile. Their members are begging for vetted content, and PMI is responding. Also, with a new chair and a new volunteer base coming into place, we have a new infusion of energy to deliver more momentum.
This week was about connecting with leaders. Mike Cottmeyer had similar relections here, and Derek Huether enjoyed happy hour the most. PMI is a great place to find passionate, dedicated leaders, who will partner with you on your mission.Â I made some very good friends this week, and I am finding that it is your friends that shape who you are.ï»¿Â You should strongly consider getting involved yourself, either as a volunteer at your local PMI chapter or with the PMI Agile Community of Practice.
Last week, I attended the most awesomest, super-cool, rock-my-world training class on collaborative problem-solving. Luke Hohmann of the The Innovation Games® Company taught a class of 20 consultants how to use his Innovation Games approach to team facilitation. Not only was the class filled with some already very strong facilitators, but Luke was able to give us some concrete tools to go to the next level.
Seriously? Games at the office?
Luke talks about a sector of the game world called “Serious Games”. These “games” are actually interactive exercises designed to get work done and attack very real-world business problems. For example…
- To understand what you need to improve, play Speed Boat.
- To understand what features you need to build into your next product release, play Buy a Feature.
- To understand new possibilities, play Product Box
- To understand how & where your product fits into the market, play Spider Web
Seriously? Any Office Problem Can Be Made Into A Game?
The full package of Innovation Games consists of 12 different interactive exercises, which you can read about here. However, that’s not all. What really blew my mind was the possibility to turn any graphic into a collaborative tool. Here’s an example. Let’s say you want to get a sense of what questions we need to answer at each stage of a project. On a large paper printout of the project stages, team members will post a sticky note to the left side of each stage. Then, team members post on the right side of the project stages a set of interactive exercises we can perform to answer those questions. So, if at the portfolio level, we want to know which projects to prioritize, we can play Buy a Feature.
As a management trainer and coach, I already had a number of collaborative exercises in my toolkit. But now, I have over a dozen more to choose from, as well as the foundation to create an infinite number of situation specific games. If you are a trainer, speaker, consultant, or team leader, then I strongly recommend you go sign up for this course (not an affiliate link). It will make you dramatically better at working with knowledge teams.
Given that I’m in the midst of a major career transition, I’ve been reflecting back on the highs and lows of my years as an IT professional. It’s been a rewarding exercise, and I’d like to share some of it with you here in the next couple of posts. And what better way to start than with one of the worst days of my life.
In my first job out of college, I was a computer programmer on a large government project. After about a year or so on the job, a senior team member (let’s call her Terry) was promoted to manager. With that promotion, our relationship changed from senior-junior colleagues to superior-subordinate. What I didn’t realize was that she brought into her new role some initial impressions and expectations of me as a professional.
ï»¿After one particularly bad month, she called me into her office, and started unloading. I can’t remember the exact words, but they went something like this…
Jesse, you really messed up that last software module. Because you weren’t able to figure out the solution, your team lead had to come in and finish it for you. Consider the impact of that, Jesse. Because he spent so many hours helping you, his own assignment was late also. Remember the last time this happened?
…um, no I don’t. When?
It was the file manager. Remember how much trouble you had with that? Don’t you realize there is a pattern going on here, Jesse? Now, I’m left wondering if I can give you anything substantive to work on, or if we’ll just end up having to send someone else bail you out of the next problem. In fact Jesse, I simply can’t believe you spent so long on the module without getting anywhere. I think you knew your team lead would be there to bail you out and so you didn’t try as hard as you could have.
…are you saying I messed up on purpose?
That’s what it looks like. I don’t know what to do with you, Jesse. But whatever your issue is, you need to fix it, FAST!
Step 1: Get expectations out in the open.
Yeah, it was that bad. ï»¿But when I look back, the root cause of her blowup was simple human disappointment and frustration. From her perspective, I was the key issue. But the real problem was that I had no idea.. She was viewing my previous difficulties as a liability, and had put me on a secret probation. Instead, the two of us should have known way ahead of time what was expected of me.
- For managers, you need to be 100% positive your team members know what you expect of them. When you move into a new leadership position, you should have both private and group discussions about what people understand their roles to be, what the team expects of you, and what you expect of them. Obviously, Terry didn’t do that, so I was left to continue my current work style, setting me up to fail.
- For team members, just because you’re not a manager, that does not mean you’re not off the hook. Expectations are a two way street. Namely, if Terry didn’t initiate the expectations chat, then I should have. I learned this from the One Minute Manager books by Ken Blanchard. If you as a team member don’t know where you stand with your boss, supervisor, or manager, then it’s up to you to fix that problem. Ask for a meeting with your boss to ask “how can I best help the team? What skills do you want me to focus on?” If your boss doesn’t give you the for that conversation, then at least send her an email spelling out your own understanding of where things are (heck, email is formal written documentation, so if anything you’ve generated some positive input for your next performance appraisal).
Step 2: Vent first, then confront
Because of Terry’s delivery I couldn’t hear her message. Instead, I internalized it by posting this little self-pity manifesto on my cubicle wall:
- For managers, no matter how frustrated you are, don’t confront your team members in the head of the moment. Let’s say you are boiling with frustration over a team member, someone who gets you so enraged that you know you can’t control yourself right now. If that’s the case, then right now is not the best time to confront him. Instead, go to a peer or to your own manager, ask for permission to vent, and then vent. If there isn’t anyone good to vent to, then go vent in the bathroom mirror. But whatever you do, don’t go to your people, with full engines revving and unload on them. ï»¿
- For team members, this is NOT how you deal with an unreasonable boss. First, it tells her that yelling at me is okay. Second, I allowed the intensity of the message to drown out the critical feedback that could have made me better. Looking back across the years, I really wish I had done some venting myself. If I had confided in a co-worker to get some additional perspective, I could have gotten past the episode. But I didn’t do that. Instead, I let the emotions get the better of me, and I held a grudge. In fact, some 8 years later a very similar situation came up, and I did confront my manager about a tirade. This time, because I took the risk of first venting, then confronting we were able to get underneath some stuff, and build a much better working relationship.
“I’ve been meaning to talk to you about that”
At this moment, Terry was taking a risk. She’s in a rational state now and wants to follow up after the poor confrontation. And my epic response was
“Don’t worry about it. It’s an inside joke.”
Yes, I know. That was really wimpy. After my response, she smiled and left, and that was the end the conversation, and our working relationship. I soon started looking for a new job and turned in my notice a few weeks laterï»¿.
- For managers, even if you or your manager exert the emotional discipline not to blow up, even if you take the risk of a rational confrontation, there is still the need for ongoing follow up. ï»¿ï»¿ï»¿Terry did just that, but gave up when I made it hard for her. As a manager, you can’t take no for an answer. Yes, I wish I had responded better, but I also wish she said: “Well Jesse, regardless, I’d like to have coffee with you this afternoon to work through our last conversation. Meet me at Starbucks at 3pm”. This is what is expected of leaders; this is why you are chosen for the role of a manager. Because Terry didn’t go that extra mile, she lost me the opportunity to steer me into a productive team contributor.
- For team members, if your manager follows up with a peace offering, then it’s your obligation to accept it. Furthermore, if she never does follow up after yelling at you, then you need to initiate that. I held onto the grudge, and I lost the chance to grow through the experience.
So, when it comes to managers losing their cool. It’s a two-way street. Prevent it with open expectations. Control it by venting first. Resolve it with intentional and determined follow up.
QUESTION: Have you experienced similar conflicts? What worked or didn’t work for you?
This month’s PM Network Magazine features the latest installment of my “Agile Project Manager” column. You can read the column here (PMI Login Required). But In case you don’t have a PMI membership login, I’m posting the column below:
One team flounders in the best of times while the other flourishes in the worst of times.
I recently coached two project teams implementing agile. Letâ€™s call them Team Flounder and Team Flourish. Team Flounder started with full management support, complete with expensive training and consulting help. However, six months later, the initial boost wore off and the team stabilized at a productivity level best described as okay. Team Flourish was given the worst of circumstances. Looking to avoid any notice by stakeholders, the project sponsor ordered the team to slow its progress. Furthermore, prime and subcontractors were at war. One year later, though, the project had accomplished more than anyone had hoped. Both teams had implemented the same methodology. Why did one succeed where the other struggled?
Iâ€™m convinced the number-one reason why projects fail is that the wrong people are on the team. Agile doesnâ€™t solve your people problems. Rather, techniques like daily stand-up meetings and retrospectives are intended to expose people issues more quickly and nudge you in the right direction. To help filter out those who donâ€™t fit a given project team, leadership author Bill Hybels offers the following criteria:
- Character: People have to possess the mettle to do the right thingâ€”as a team. Team Flounder suffered under the rule of one senior knowit-all who disparaged his peers. It took six months before the project manager fired the guy for the ongoing harassment. It was a relief to have him gone, but team members were left wondering if management would take that long the next time. Meanwhile, Team Flourish was under attack from a vendor. In response, the team formed an alliance with a few trustworthy contractors while staying firm with adversaries. It survived the sabotage and continued delivering.
- Competence: Technical knowledge isnâ€™t always enough. Team Flounder had a chief engineer who was undoubtedly smart, but she wasnâ€™t the strong leader who would help team members grow. Team Flourish found itself in a feud with several buzzword-certified braggarts steering the project in the wrong direction. The core team spent weeks building an evidence-based case for the right strategy, and it worked.
- Chemistry: Project managers often treat team chemistry as fluff and then are stumped why productivity is so low. When Team Flounder filled the roles of product manager and process manager, it followed the methodology rules to the letter. The problem was the two people picked didnâ€™t get along. Every time one of them said something, the other felt undermined. As a result, the rest of the team was stuck without any clear direction. Team Flourish, on the other hand, was ruthless about pruning people who didnâ€™t quite fit. The result was the strongest team dynamic Iâ€™ve ever seenâ€”one that equipped its members to overcome all that weirdness of competing stakeholders and volatile project scope.
In the end, agile isnâ€™t a silver bullet. The fate of projects is determined by people, process and technologyâ€”in that order.
A couple weeks ago, the PMI Washington DC hosted a webinar by Agile practitioner Joe Luttrell. The talk was call â€œProject Management: The Ultimate Calling?â€, and it blew me away. You can download the slides, but they donâ€™t convey the full essence of his story.
Whatâ€™s Happened Before
Take a look at these facts:
Granted, I took some liberty by adding in the the observations about the Agile PM movement, but the overlap is uncanny. CPM, the PMI, the PMBOK, even the Agile movement were motivated by a shakeup in the business economy, or to cut to the chase:
When the market suffered recession, the market reacted with a further maturing of project management.
Joe also offered an analysis of what the next innovation in project management might be, by taking a look at digital technology. While most futurists declare us to have entered into the Knowledge Age or the Information Age, Joe noticed emerging technologies are mostly centered around communication. The Cell phone, CD/DVD, PDA, internet, PDA phone, Wireless, intranets, and social media are all communication media. Granted, communication is how knowledge and information is created. But look closer, and youâ€™ll see these technologies are also progressively more collaborative. Itâ€™s more than an information age weâ€™ve stumbled into; itâ€™s a â€œCollaboration Ageâ€.
This collaboration dynamic is a having a game-changing dynamic on management. Work used to be done under a centralized control structure. From customer support call centers to outsourcing vendors to teleworking professionals, work is increasingly decentralized. As it becomes more distributed, collaboration becomes the power play that differentiates one team over another. In yesterdayâ€™s world, the one with the most control over resources was the winner. In todayâ€™s world, the one with the most distributed and collaborative power structure is the winner. Nobody is making serious money on social media, but everyone is raving about itâ€¦because we know that collaboration is the new killer app. Well isnâ€™t that what project managers do? We corral a variety of players from all departments toward a common goal.
Joe concluded by giving us 3 concrete techniques we can employ to become those collaborative project managers:
- Progressive Collaboration â€“ Working together is a fluid endeavor. You learn each otherâ€™s habits, styles, interests, and preferences. And as soon as you get to know one another, someone new has entered the project. You canâ€™t figure this collaboration thing all at once. You have to adapt to people along the way, and you have to persist through the annoying personalities and awkward moments
- Conflict Confrontation â€“ Joe reminded us that there are 3 ways to resolve conflict: Compromise (lose-lose), Smoothing (avoidance), or Confrontation. I struggle with this. I am a people-pleaser by nature. Even though I know putting an awkward issue on the table is the most effective thing to do, I get anxious about it. I get it, but that doesnâ€™t make it easy.
- Decisive Facilitation â€“ As you can imagine, â€œcollaborationâ€ does NOT mean sitting in a meeting for hours on end, listening to everyone ramble, and beloabor the points over and over. Instead, be an intentional leader of any meeting. Know what decisions need to be made, so that you can drive discussion towards that goal.
If you canâ€™t tell, Iâ€™m inspired. We are about to ride a the wave of a collaboration revolution. Our teams are relying on us to be the leaders that guide them along that wave. If you commit to developing these three skills, then you be a project manager that helps to change the world.
We’ve all suffered it.
Jane in the product design department is upset she didn’t get a budget increase, and Steve the Director of sales is upset she was promoted to VP sooner than he was, even though he had more tenure. Meanwhile, Todd the company’s chief counsel is so focused on limiting liability that Michelle the VP of Marketing feels stiffled in what she can do with a promotional campaign.
Whether you call it “silos” or “parochial thinking”, office politics affect just about everyone. It’s that organizational tunnel vision that slowly seeps into our work. Mission statements, corporate values, or the latest process improvement effort all fail to motivate workers toward a common vision. It seems no matter what leaders do, people still fall into old patterns. Enter Patrick Lencioni.
I’ve been wanting to read his books for a long time, so a couple weeks ago I picked up his book that attacks this topic head-on. Silos, Politics and Turf Wars describes the problem and solution in the format of a “fable”, a fictional narrative that gets the point home without the embarrassment of naming anybody in real life. The solution, as it turns out, is the age old proverb: “Never waste a crisis”. Lencioni observes that organizations and teams really come together in the face of a collective emergency. In the ER, a hospital’s organizational departments come together to save a gunshot victim. In a failing company, teams pull together to stave off bankruptcy. In a startup, the energy of a grand idea inspires people to a goal larger than their own turf. Over the course of a very quick read, Lencioni formulates an approach for tapping into the substance of a crisis, without have to suffer through the pain of a crisis:
What is your organization’s or project’s top priority right now? This is your “Rallying Cry”, the single most important goal for your team over the next 2-6 months. It needs to be succinct and simple. An example from the book would be “Complete the merger and launch the new company”. While this may be a compelling motivator, it’s a little vague. What exactly needs to happen to accomplish this goal? That’s the next question.
What component goals are need to accomplish the Rallying Cry? These are your “Defining Objectives”. What would it look like if this Rallying Cry were fully achieved? What are the components of this primary objective. Decomposing our example above, we might want to “Clarify the product offering”, “Simplify the org chart”, and “Establish the new brand”. These smaller, more tangible goals help to put real meaning into the Rallying Cry.
What regular ongoing responsibilities must be met, just to survive? These are the tasks that *have* to be done, regardless of what the highest priority is. No matter the rallying cry, a project has to deliver and an organization has to generate revenue. A key to combatting turf wars is to acknowledge that a given office is still important, even if it’s not the most important thing right now.
It turns out this model is so effective, he wrote another book that he uses it to provide clarity for the average frantic family life (The Three Big Questions for a Frantic Family).
There you have it. A simple 3-question approach to adding context and clarity to the chaos of your own organization. I’m wondering what yours would look like. How would you use this approach to describe your organization’s key needs right now, and describe it in such a way to motivate your team?
I was mulling over how our project team might get better at doing Agile / Scrum, and stumbled over two proverbs that capture the substance of our efforts:
“Perfect is the enemy of good” – Voltaire
“Good is the enemy of Great” – Jim Collins
When contemplating the truth embedded in these statements, I wondered if they could be mashed up to yield a new cliche’ of my own:
“Good is a Necessary Evil” – me
Let’s unpack this a little more, using a few more colloquialisms along the way…
- Good is a Necessary Evil – Too often, we get so hung up on the way things *should* be, we refuse to accept any things else. Methodology snobs and process wonks declare that if you don’t do it (CMMI, Scrum, PMBOK, or Six Sigma) all at once, you can never be sure you’ll do any of it. Certainly, there are points to be made in favor of all-at-once process improvements: it creates the right kind of mess (aka “creative destruction“) and it forces commitment up front. However, the other maxim of crawl, walk, run reminds us that you can only be successful one step at a time. Don’t bite off more than you can chew, or you’ll never generate the confidence you need to push forward.
- Good is a Necessary Evil – Although the trip of a thousand miles starts with the first step, the danger of starting small is staying there. A little bit of success can dull our desire to get better, faster, cheaper as an organization. We as a team have to express, and re-express our commitment to continuous process improvement. The “evil” associated with being good, is that insidious notion that we’re good enough to rest. Surround yourself with a group of individuals that are ruthlessly devoted to getting better one step at a time, and you’ll be more likely to resist the temptation to do so.
Those are my meandering thoughts for the week. Now, I have to go back and count how many oft-repeated truisms and buzz-phrases I just mashed together…