Effectiveness is the new Gorilla

- Or, saving time does not save work.

[Before we dive into another, great Gorilla, I'd like to ask a favor. If you find these blogs informative, please post a comment. If you find them really valuable, please tell your friends, tweet the link, mention me on your Facebook. The only way I know if my advice is helpful, is if I hear from you. - Thank you - ]

My head hurt. The stack of work before me could have doubled as a small skyscraper. No matter how hard I worked, I'd easily be pulling twelve hour days for the next two weeks. I had to find a way to be more efficient. I needed a way to speed things up, wipe a bunch of this work off my plate as fast as possible.

My eyes fell on the project training and adoption plan. It was the largest component of the communication plan for the project. It was a two hour, interactive training program that would ensure every single person involved in the project would be on the exact same page. I'd finally finished the slide deck. I'd just gotten the last sign off from the project stakeholders, that the training accurately covered all their needs and issues. I was now staring at the global calendar system in utter dismay. With people spread all across the globe (we have a coder in Antarctica, seriously?), it was going to take at least three weeks to roll out all the training. Then I'd have to compile all the questions into an FAQ, send that out and circle back with all the key stakeholders again. It was a nightmare, I'd be spending so much time on this, when would I manage the actual project?

Suddenly I had a triumphant idea. It was brilliant, it was easy and it was efficient! I'd cut three weeks off the planning phase in ten minutes! With glee I opened my email client. I found the email list I needed,  Division_Head_Honcho_All_Employees, I'd send the deck out to everyone with instructions to review it and send any questions they had to me. And to save time on hunting approvals down, I'd write the email so that if they didn't respond, approval was automatically assumed.

Pure GENIUS!

<SMACK!> The banana careened off my skull and into my monitor, knocking my poor flat screen over like a high tech cow tipping.

Spinning around I shouted, "HOGARTH! What the hell was that for!"

Hogarth sauntered across the room, stopping to pick up the banana, and began peeling it. He took a large bite from the end, before waving the banana in front of my nose. "Let me ask you this. Suppose you've got one of those cute little Smart cars. You know the ones just a bit bigger than a carry on suitcase, get 43 miles to the gallon."

I nod knowing anything else would potentially result in another banana to the head.

Hogarth continued, "That is one efficient car, no question about that. But if I leave the parking brake on, or let all the air out of my tires, then no amount of gas efficiency will make that car effective."

Ah yes, the Efficiency is not Effectiveness Gorilla.

Frying eggs for my next four breakfasts, all at once, might be efficient but it surely isn't effective. And I really won't be looking forward to cold, fried eggs for the next three days.

Dictionary.com defines Efficient as:

Performing or functioning in the best possible manner with the least waste of time and effort; having and using requisite knowledge, skill, and industry; competent; capable: a reliable, efficient secretary.

It defines Effective as:

Adequate to accomplish a purpose; producing the intended or expected result: effective teaching methods; effective steps toward peace.

On the surface, they seem very similar. However efficiency focuses on the "least waste of time", while effectiveness is about "producing the intended or expected result". It doesn't matter if you complete the three hour test in 30 minutes, if you only get ten percent of the questions right. You have been time efficient, but you did not get the desired result, to pass the test.

A Practical Example:

In a previous job I was responsible for managing the program to ensure a multi-hundred person team was ready for the release of a new product suite. The team had no control over what the product suite would be, but did have to make major changes to how it did business, what tools it created/used and how its people were trained, in order to be ready for this product suite release.

The program team for this project was over thirty people spread out over more than a half dozen global locations. Team members ranged from individual technical or process contributors to heads of entire teams that would have to support the new product suite. Of these team members, none was  above a senior manager role and the project sponsor was only a director. It was a challenge just to communicate with the team and the act of bringing them all into alignment and working to the same cause was daunting. At a fundamental level, the entire organization was going to have to change better than 40% of how they conducted their daily work.

Early in the project work I identified that the team was going to need proper decision making empowerment and end to end support. This required communication and buy in with well over a hundred individuals, ranging from the senior exec, of the division, down to individual subject matter experts. In an era of multi-thousand person 'corporate initiative' emails, it would have been very easy to blast out an email outlining the whole process, with a fancy hundred slide power point presentation to cover every contingency. I could have done this in less than a week and have not just those key one hundred people, but the entire division fully briefed on the project and what they had to do.

Very time efficient, and very ineffectual. Instead I spent a month focused on project initiation communication. I wrote individual emails, met one on one with people and created 'commitment contracts' from the VP on down to the SMEs. Everyone knew what their role in the project was, who they were accountable to, who was accountable to them and how communication would flow.

When the product suite finally shipped, the division was more prepared then they had been for any other release in company history. The war room set up to handle post release issues lasted only a week and was almost entirely focused on issues that cropped up from other divisions not being prepared. Quality metrics for the division, which had always gone done right after a major release , didn't just hold steady but actually improved. The division knew more about this release than any previous release. Instead of spending the first three months learning, they were ramped up from day one.

At the end of the project, four weeks of work saved countless hours, dollars and people stress. At the project start, it didn't seem to be a very efficient use of time but it was very Effective.

Being Effective:

Anoop Grover, a Silicon Valley IT project management expert, spoke at a recent PMI event on comparing Waterfall vs. Agile methodologies. At the event he said to the effect "I don't care what method you use, what I care about is the outcome. Did I get what was intended." He went on to balance this by stressing that any project must communicate clearly and often up and down the chain. At the same event, Jeff McKenna, Scrum luminary, shared a story that essentially boiled down to "Under this new model, you promise me ten features and always deliver at least nine. I also know that if you don't deliver a feature it will be feature 10. I can plan to this and know what to expect." If your senior management knows what to expect, then they have more trust, more trust makes for a much more effective organization.

When tackling an issue, ask your self what the desired outcome is. Ask yourself if the way you've been doing things is efficient or effective. Take the time to understand what your stakeholders and team want, expect and need.

You'll save time, and bottles and bottles of antacid.

Joel BC

Veteran, the Project Manager wars

Want me to talk to your gorilla? Send me an email

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

The Stealth Gorilla

Or- How to enact change control under resistance.

The office was deserted. Only a few lights burned like pools of florescent haze.Using the light cast off of my monitor to see by, I typed furiously at my keyboard. My masterpiece was nearly complete. I lovingly stroked the cover of a book lying just outside the illumination cast by the monitor. "Soon, soon my precious we shall have them following process. We shall have the one true way." Sliding the book into the light, I gazed at the cover. The MoPRoK, the Management of Projects Repository of Knowledge* would make all things right. Tomorrow we would start fresh, we would wipe the slate clean and start following the plan from A to Z. Finally we would have process and all would be good!

I was about to release a maniacal cackle of glee when my thoughts were shattered by a flash of steel and the dull thunk an object striking something. Looking down I saw a shimmering metal star vibrating in the cover of my beloved MoPRoK. Spinning about in my chair I caught site of Hogarth. At least I was fairly certain it was Hogarth, I couldn't be certain with the absurd black outfit he was wearing. But it was hard to mistake those mischievous eyes peaking out from the cloth over his face.

"Hogarth, what the hell are you doing?"

Striking the most absurd pose I've ever seen on a gorilla, and that is no mean feat, Hogarth hissed "I am Neeeeenjhaa!" He made a series of moves that I could only construe to be his interpretation of martial arts moves. I must stress "interpretation" when I say this. Gorillas were not designed to be Bruce Lee.

"What on earth are you talking about?" I asked.

Sliding towards me, Hogarth began speaking. His lips were moving in rapid succession as he did so in an obvious, but poor, attempt to mimic bad comics mimicking bad martial arts movies, "I am the process that slips through the dark. I am the template that appears unbidden. I am the change that happens when no one is looking. I am, Stealth Process!"

I rolled my eyes with a groan. "You can't be serious? I am not going to don a set of black pajamas and sneak through the office."

Hogarth pulled a bright yellow banana from a hidden pocket and perched on my desk. "Oh I definitely don't recommend the black outfit, people already see you as the harbinger of creative death."

"What? Now listen here, I'm just following industry standard process. There are hundreds of thousands of MPs using the MoPRoK. There is a process and it works."

Hogarth spoke around a mouthful of fruit, "Uh huh, and if you were setting things up from scratch, then that might just work. But you're not and it won't. This team is about as open to change as Fort Knox. You're trying to change a raging river with nothing more than a kayak paddle. It ain't gonna happen."

Sigh… And once again the ever practical Hogarth spoke true words of wisdom. The Stealth Gorilla was here to show me the errors of my ways. So now we take a practical look at how to bring about change in an organization that is resistant to change for any number of reasons.

Process can be good. Process can be great. Process can be wonderful. It can create predictability, accountability, reliability. It can assure proper communication. It can help define just what is "done". It can do everything but walk the dog (well maybe it can). But no process works in a vacuum.  And when your team is highly resistant to change it won't matter what process you roll out, it will meet resistance.

You can't just wholly drop a new process into any organization. And when you have a change resistant organization, then the challenges increase ten fold.

Enter the Stealth Gorilla.

It's a fairly simple process, which ties into one of my Gorilla Project Management  maxims. "First step is to get it done, then figure out who owns it."

Several companies back I had the pleasure of interfacing with the Sales organization. I processed special exceptions to what was supported in our products. We'd originally had no process around this at all. This was good (sales always got the exceptions they asked for) and bad on many levels. Sales was never really sure if they had buy in on the exception. Support felt they got dumped with all the weird stuff and Engineering found itself fixing bugs on things they never intended to support. So we needed a process, but getting the Sales team to adopt any kind of process was akin to getting the UN to agree on the definition of Hurly Burly.

The first was to start documenting everything. The only process we had was Sales sending an email requesting (and expecting) approval of the exception. So I started there, documenting everything they asked for. Picking up the phone and calling the sales guys to ask questions and make sure all the information was captured. I went back through the backlog of old requests and updated those as well. All this was posted in a common location, so everyone knew what was out there. Now the company had a common understanding of what had been promised to customers. I kept doing this for several months, slowly refining a submission template.

Then I started sending the template back to sales with questions, "Do I have this right?" I particularly worked with the major thought leaders in sales, showing them the value of complete data by ensuring request that had all the data were fast tracked through approval. Eventually I started getting pre-filled out templates. After another few months, we flipped things around and Sales had to fill out the formal request form to even have an exception looked at. From there we slowly ramped up process on the approval side. I'd work with the sales rep to understand the business impact, we'd compare that to the cost of supporting the change and so on. Eventually, we would make it to a point of making fully qualified cost benefit analysis on the exceptions.

"But that's so much work, I don't want to work that hard."

No one ever said project management was easy. If we wanted an easy job, we would never have taken on a role that often has mountains of responsibility and a kids shovel of authority. Yes, it is hard work I will not deny that. But it is effective work and effective is what matters. In my example, we created predictability, common understanding, a formal approval process (we even started turning down many sales requests) and in the end we took the process from roughly eight to ten weeks, to, on average, twenty days. With a little investment in time and effort, we created a process that worked for everyone and made the company more effective.

If we'd just slammed down a process and mandated Sales go through it from day one, I have little doubt they would have just stopped asking and figured out a way around the system. Instead we made them a part of the process and they ended up owning the process just as much as everyone else involved.

When you run into resistance, take a page from mother nature and practice a little erosion. Work slowly and make it easy to start. Then, like a good video game, add more and more complexity until you have a complete process everyone is bought into.

Joel BC

Veteran, the Project Manager wars

Want me to talk to your gorilla? Send me an email

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

*The MoPRoK is an entirely made up name intended to represent any number of "bibles" for how to do project management. There is nothing wrong with bodies of knowledge and I support them fully. It is all in how you implement them.

Company Culture is more than words

Or- your culture is more than your developers.

[Disclaimer: This is based on observing the industry and an amalgamation of many peoples past job experiences. It does not represent any one company or person's experiences, past or present. ]

I was doing everything right. My laptop was closed, the projection screen showing a high level status dashboard, as I focused on looking around the room. Pen in hand I was ready to capture actions and issues that came up in the meeting. I was making sure to focus on saying "we" and not "I", asking short questions and not monologing. In short I was being the perfect project manager.

And the meeting was an absolute total failure.

Bob was slumped in his chair, offering monosyllabic responses to questions that he once went on for minutes at a time. Tech Writer, Sue's fingers were unusually still, odd given she usually can put in a 1000 words during a meeting. Even James, the intern was unusually "un-chipper". I'm pretty sure he was doing the Smart Phone prayer and updating Facebook under the table edge, James never used to use tech in the meetings.

"So, Jake" I ask the engineering manager. "Where are we with the plan for how we'll update the web store once we release?"

Jake give a non-committal shrug. "I'm waiting for a response back from IT. "

I blinked, biting back and urge to sound frustrated. What the heck was going on? We were three quarters through the release. Things were going great, no major bugs, issues, risks. Heck the brass had even thrown a 'developer's BBQ' just last week to show their appreciation for all their hard work. Why the hell were they acting like someone had died?

"Someone did," and like a bad stock tip Hogarth was perched on the edge of the table.

Deeply annoyed I said, "now what? Their some of the best paid devs around, they just got a party, the brass just got done talking about how valuable they are. Why are they acting like it’s a funeral?"

"'Cause culture is more than your developers…"

So we're going to talk about a pretty ugly gorilla today. 

Tell me if you have heard this?

  "Our culture is who we are."

  "Investing in all of you, is how we will succeed."

  "Together we win."

  "It is our employees, that make us so strong."

All right, following me so far? I'm sure most of you have sat in a company all-hands and heard something similar to this. Now some companies have done an incredible job converting these words, into reality. Google is famous for its culture, Japanese car companies at one time were the epitome of this. Read Fortune, Fast Company or any other leading business periodical, you'll find showcase articles. Fortune actually devotes an entire issue to it, every year. Oh and it's not a high tech thing either, Fortune's 2009 list had a financial company, a  super market chain and a hospital all in the top ten. One of the things that makes these companies so compelling, is how they create a bond of trust and respect with their employees.

"Yeah sure," mutters Hogarth, "but you don't mean payroll right? We can outsource payroll and save a bundle." Peeling an onion, he takes a big bite. Talking through spray of onion bits he asks, "How about IT? Everyone's cutting IT now. Give a months severance and get 'em out of the way so we can focus on the real company. I mean after all, we don't need them to ship the product, it's the developers that matter, right?"

And the "What is culture" gorilla looms over the discussion.

Some companies have conducted these "streamlinings", "resiliency protections", "austerity measures" and in the process managed to shatter their corporate culture. 

Wikepedia defines corporate culture as,  "The total sum of values , custom, traditions, meanings that make a company unique." That's the total sum, not just the developers or core money makers, but the total sum of the company. 

One would think that we would have learned from the last downturn. The Dot.com crash was just a decade ago, but I look around, not just the high tech industry, but corporate America as a whole and I see the same patterns.  Companies are slicing through their budgets like a drowning man .

 It's a proven fact, that companies that invest in their employees, have more productive and happy employees. They are often noted for their innovation (look again to the example of Google or Apple).  They do not always have the largest market share or the biggest bank roll, but when it comes to people wanting to work there, they have people camping in their lobbies to try and get an interview.  I no longer remember the name of the company, but one of the most striking companies I ever heard about, was in an article in Fortune. It was so compelling, I actually sat there and thought about how I could change industries and move across the country, for a chance to work for this little 400 person company.

I'm not saying companies have to hold onto every employee, never outsource and never change, but they can't believe it won't have an impact on the survivors. Tina Turner sang in one of the Mad Max theme songs "the living will envy the dead." If a company is not careful, they will shatter their culture in the process of surviving. There are dozens of companies in Silicon Valley that probably could have survived, had they been intelligent about 'right sizing'.

So what can you, as the project manager, do? Unfortunately there is little you can do about what a company may or may not do with "right sizing", or how their "austerity measures" upset employee morale.  What you can do is be an even better listener. Spend more time on your Project Management One-on-Ones, your MBWA (management by walking around). Give people a safe outlet to vent and talk. Often that's just what they need. Go crack open 7 Habits and review your empathic listening skills. But remember! You still work for the company. You don't bitch about the changes, you support them and you support your team. You listen and you keep being effective and there.

Joel BC

Veteran, the Project Manager wars

Want me to talk to your gorilla? Send me an email

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

I can see you Gorilla

The program team meeting was progressing. Progressing might be a strong word, maybe it was crawling along like a drunk slug in an ice storm. I looked down at my screen, scrolling through several pages of data in silence before half looking up again. "According to the reports, we have four P1 blockers on the release, Jake what's the status?"

Bob's eyes half flicked up from his computer screen before registering that "John" sounded nothing like "Bob". The two Tech Writers were splitting their attention between a marked up manual and their open Macbooks, while James the intern was sitting up in his seat hand poised over a notepad ready to capture something important.

Jake on the other hand was at the far end of the table head down at this open laptop and fingers screaming away. It seems in the time it took me to find the data I was looking for Jake had decided to recode the entire database architecture.

"You know," Hogarth drawled leaning over my shoulder to look down the table.

I waved off Hogarth without looking up. "Hang on, Hogarth." I tapped furiously at my computer, hitting enter to the satisfying sound of <ping>.

At the far end of the room my computers little voice was answered by a corresponding <ping> emanating from Jake's computer. Jake's fingers paused.

Hogarth looked at me, "You did not just Facebook chat that engineer!?"

I looked up at Hogarth, trying to give him the stare that said 'Do you have two heads, cause you make no sense?'. "Yes, I wanted to make sure I got his attention."

At this point Hogarth made sure he had my attention. <SMACK>

"Ow! What was that for?" I demanded of my gorilla.

"For gross idiocy in the running of your meeting."

"Me?" I exclaimed. "I am not the one rewriting the codebase to the Library of Congress in the middle of the meeting!"

Hogarth gave me 'the look'. The one that told me he thought I'd just said about the stupidest thing in the world.

And he was right…

As the project manager, the way the meeting runs is your responsibility and yours alone. And how you conduct yourself is the first and most important thing you need to focus on.  I don't know if it is a Mark Horstman original, or a re-quote, but he has often been heard to say "When looking for the source of a problem, start by looking in ever increasing circles about yourself."  In other words, the examples you set will be the examples your team follows.

Computers in meetings is a major area of contention. The Manager Tools team make no bones about it, if they are coaching you and you insist on taking a computer to meetings, they'll drop you as a client. Hear that sound? That's the keening wail of protest coming from Silicon Valley. "But I take notes, I have data, I, I,I…" I could go on. Heck I've said most of the excuses myself, and as much as I hate the concept of taking my hands from my precious keyboard, Horstman is right in so many ways. No matter how professional you are, the minute that screen flips up, a small part of everyone's brain assumes you are doing something else. And come on folks, we all have been guilty of doing just that. "Oh well, I'll just check that one email," "Hey look, there's that error in the code," "Ooh, Diane updated her Facebook with photos from last weeks beer bash," and so on.

Now Manager Tools makes a lot of good points and I admit to not being as good as I could be. When I am attending a meeting that someone else is running, I try very hard to leave the laptop at my desk. Taking notes on paper is really much more efficient. Yes it requires you to copy it into the computer later, but you have more flexibility with the MK I pen and you are being more professional and more focused on the meeting, not your technology. Heck, the act of transposing to the computer will lock the meeting in your mind all the more.

The biggest argument I hear to this is "I have information on my computer that I might need". I can't argue with that, but I can argue that you don't need to have your computer open the whole meeting. Need to give an exact answer on the sell through rate of the NewCo Gizmo? Then open your computer, look it up and then close it again.

"What about when I'm running the meeting? I am the project manager." Right you are, but there are rules here as well.

·         If you are not presenting, then close the computer! The reason to have a computer in the meeting is to share data with the whole team. If you are not sharing, then you are shutting out your team with lid of your laptop.

·         If you're not typing, close the lid. Many times the information on the projection screen is just for reference and the main talking happens in the room. Close the lid and engage in the meeting.

·         Take notes on paper. Keep your notebook open and ready, jot your notes in the notebook not on the computer. Update the power point slides after the meeting, not in the meeting. If you're not in presentation mode, something is wrong.  There are some exceptions to this, but very rare and focused mostly on real time updating. Using a MindMap to create a Work Break Down structure? Then type on the computer. Need to note a reminder to schedule a meeting next week to follow up? Put that on your notepad.

A final note on taking notes.  This isn't college, this is work. You are not trying to document everything that was said in the meeting, you are capturing action items, follow ups and critical points. Manager Tools recommends the Cornell Model note taking (Yes, they even have a podcast dedicated to it). I have been using it to good effect for more than a year now.

Joel BC

Veteran, the Project Manager wars

Want me to talk to your gorilla? Send me an email

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

OpenAgile- The PMs job hunt best friend

"What'cha doin?" Hogarth's question was nonchalant and as innocent as a cat burglar caught hanging from the ceiling.


"Remember when I was out of work last year," I said. "I tried to apply project management discipline to my job hunt, but it just ended up being a revolving to do list. I think if I use OpenAgile, instead of Scrum, we might really be onto something."


Dropping onto the couch next to me, Hogarth pulled out a banana from… Well some mysteries are better left that way. Pealing the banana he asked, "How come?"


I looked over at him, "Well for one thing, it wasn't much of a Scrum team with just myself and my gorilla."


Hogarth sat up, an indignant look  on his face, "Scum?! I'll have you know my father was a silverback for one of the largest bands in the Congo!"


I rolled my eyes, "Not scum, Hogarth, Scrum."


My 900 pound gorilla quickly deflated, "Oh." Looking at me he said "We're not going to France either, are we?"

"No, were not going to France..."

Hello and welcome to a practical Gorilla blog on using the OpenAgile Methodology for conducting a personal job search (For those confused about going to France, or what OpenAgile is, check out my last Blog where I review OpenAgile).

If you haven't checked out OpenAgile yet, it will help to at least have looked at the Process Reference sheet. I've put an image below, but it will help to have the actual PDF. To get a full understanding, go and grab the OpenAgile primer.

I'm going to go back to my own job hunt here. Like many Project Managers, I set out to tackle unemployment like it was a project. A nice a firm start, middle and end (A job). I can't speak for other PMs, but I found that once I rolled up my sleeves and got into the search, I was just working from a task list. I had a loose method going, but I wasn't approaching my search in a manner that allowed flexibility or repeatable structure (yes, you can have both in a project). My search became disjointed and often interrupt driven affair. It turned out well in the end, but I think if I had OpenAgile, things would have gone much different.

A traditional Waterfall methodology really isn't going to work well for running a job search project. A long planning cycle, followed by development before ever getting to Qaulity feedback means you could be applying for a job that was filled two weeks ago.  At the same time, Scrum isn't really the right fit either. Scrum is targeted at a teamwork process, with clear roles and is still very much geared towards a software development cycle. I tried using Scrum for my last job search and found it to have too much unusable overhead (which for you Scrum Masters our there that has to sound funny).

OpenAgile on the other hand has a very open structure, that can be easily adapted to nearly any kind of project (Perhaps OA Exec Direct D. Parker will do a blog someday on how he used OpenAgile to organize his cross country move). Where even Scrum has a Scrummaster, Product Owner, and Team Members, OpenAgile has only the Team Member, with facilitative work of Growth and Process facilitator potentially being all wrapped up in the same person. Almost makes me thing of OA as the zen Agile practice. "There is no spoon, you are growth and process in the same being."

All right!, enough theory, how would I use OA to job hunt?:

Cycle Length: Weekly. You want to be highly responsive during your job hunt, so a week is the best cycle time. Further, a cycle is Monday to Friday. You may be out of work, but weekends shouldn't be scheduled. You need down time and if you have a strong process for job hunting, you can take that down time.

Value Drivers: This is an area little covered by OpenAgile. OA is focused on the execution (which is a good thing) and doesn't currently have a body of knowledge around the generation of the Value Drivers (Scope, Features, "What is Done"). At the high level a VD should be "a characteristic deemed desirable by the stakeholders that is measured in relation to a goal. OA also recommends that Value Drivers use the S.M.A.R.T. goal format.

In the arena of your job hunting, this is where you define what a successful job hunt and job will look like. This is BIG, but is not in the scope of using OA for the actual job hunt. OA is about executing to the Value Drivers. There is a great concept called Value Levers which is used by such big names as Intel. I promise Hogarth and I will talk about it in the future, but email me if you want a copy of a Value Driver presentation I attended this summer.

Stakeholders: A quick note on these. Obviously you are a stakeholder. But your family is also a major stakeholder. Another stakeholder you can't ignore is your bills, more to the point, the people you pay your bills to. Even your poor car can be a stakeholder. Job A is perfect! But it's 60 miles away and your twenty year old Geo Metro isn't going to hold up well for that commute.

Enough on the ground work, now to the execution:

Start at the Circle: So one of OAs key components is the Learning Circle. One of the best things about it, is you can start at any place on the circle. In this case though, we'll start at the beginning (Flip to the second page of the OA Process Reference Document).

Reflection: Time to start with brutal honestly. Or in the parlance of OpenAgile, the foundation of Truthfullness. Before you can move forward, you need to reflect on where you have been. The first couple of weeks, these reflections are hardest as you are going to reflect on the last job you held. Moving forward though, Reflection becomes a look back at the last cycle (week) and what happened. I highly recommend the Manager-Tools Hotwash podcast for conducting reflections. The concept of "What went well" and "Things to Look At", combined with an open brainstorming model are very productive. Do it alone or grab your spouse (Significant other, close friend, etc) or reflect as part of a job hunt networking group.

Learning: I love OpenAgile for this. Lesson Learned (often better known under their more morbid name of "Post Mortem") and even Agile Retrospectives too often combine reflecting and learning into the same step. If you listen to the Hotwash cast, you'll probably understand quickly enough. I think of the Learning phase as the phase where you decide how you will apply the knowledge you gained in reflecting. By separating these two steps, it is like brainstorming . In Reflection, the goal is just to think, to reflect, to write stuff down, not to try and come up with a fix or solution. The Learning phase is where you decide how you will take the Reflections and put them to use. By giving them a space, you separate the emotion from the learning. Instead of kicking yourself for not having any cards to give the guy in the Starbucks line, you "learn" from the experience and set a task to go to Vistaprint and order some cheap cards.

Obviously, I espouse separating Reflection from Learning. Taking a page from Scrum, do your reflecting at the end of the last cycle (Friday afternoon) and do your Learning at the start of the next cyle at the Engagement meeting (Monday morning).

At the end of Learning, you should have some solid tasks, or process improvements that can be incorporated into the next cycle.

Planning: Now here we are again, right at the meat of it all. It's where we Project Managers often commit our worst sins. When we are planning multi-million dollar projects, we do a great job. When we are planning out something for ourselves, we too often get lost in the weeds or fail to plan in depth. The OpenAgile process breaks down planning into five distinct "artifacts". Calendar Events, Obstacles, New Artifacts, Quality Problems, and Repetitive Activities. I can't give this section the attention it fully deserves without all but re-typing large sections of the OpenAgile primer. But let me give a broad sweep on why this is good.

Breaking your activities down into the OA manner allows you to provide greater focus and importance. I like to think of it as a practical application of Covey's Habit 2 Urgent/Important Two by Two grid. It's a way to make sure you are "doing the right things" and not getting lost in the minutia that can be the death of a good job hunt.

Calendar Events: This is just common sense. Peter Drucker spoke of this for decades. If you don't plan your schedule, you won't be effective. What meetings and events do you have? If you don't list them, you don't know when you have open time to work. If you have a task that is best done in one sitting and you think will take eight hours, don't schedule it on a day when you have a networking lunch with old co-workers.  Make sure you schedule time to work on tasks (New Artifacts and Repetitive Tasks). If you know you're best at writing in the moring (you are customizing your resumes to every job right?) , the try to schedule that phone screen after lunch.

Obstacles: Roadblocks, Blockers, Speed Bumbs, we call them many names but in the end they keep us from getting our job done (and when you job is finding a job, that's bad). Remember last cycle, you didn't have a business card to give that guy in the line? That's an obstacle to your being able to easily advertise yourself. Convinced that HR person is blocking you from advancing when you are perfect for the job, that's a potential obstacle.  In Covey speak, Obstacles are Urgent/Important Quadrant 1 activities. Fix them fast, get them out of the way so you can go back to Quadrant 2.

New Artifacts: The heart of your activity cycle. New Artifacts result in the creation of something concrete. "The creation of a document, a process, or a tool, or changing existing documents, processes or tools are all examples of New Artifact tasks." New Artifacts have to be sized (Scrum estimating here we come, planning poker anyone?).  In job hunting terms, these are your resume updates, your cover letters, your contact emails to that old friend working at Amazon. Yes, it seems detailed, but you do need to plan out just who you will be emailing or calling this week. I personally used Mind Manager for this, mapping out each job I planned to pursue, each person I was going to communicate with, etc. I updated it at the start of every week and tweaked it daily.

Quality Problems:  Very similar to Obstacles, only these issues arise during a given cycle. Like Obstacles, they move straight to Covey's Quadrant 1 for immediate action. "Wow, did I really put a resume on Monster that says I am a professional "PiMP"?, gotta fix that right away!"

Repetitive Tasks: Don't be so quick to dismiss this one. New Artifacts are going to be your big fish (Intel is hiring for just your skills, need a plan to attack this opportunity), but to get the big fish, you often need to go dig up the bait first. OpenAgile suggests an RT format of “Every ____ we will _____.” (For example, “Every day we will check voice mail.”). A big part of job hunting is the unsexy, unglamorous practice of checking your sources. It also is a way to take control of your interrupt driven schedul.., (hang on folks I just got an email). Yes, that's right, stop looking at your email every 60 seconds. This harkens back to Drucker and Manager Tools, schedule three times a day to review your email. Make them set times with a start and end. Make them the same time every day. That's repetitive and that's good time management.

A final thought on repetitive tasks, and I know this is going to sound silly, but I speak from experience. Job hunting is a job, give it set hours. In my last job hunt I didn't do this too well. All to often my Wife would come into the home office and remind me "It's 6PM, are you coming to dinner?" A repetitive task can be a simple alarm to remind you to wrap up and end your "job" for the day.

And ACTION! All this blogging and technically we just finished the engagement meeting at the start of the week. Now that you have a plan, time to take action. You've got your tasks on the task board, you've scheduled your calendar and repetitives, you know what the Quadrant 1 obstacles are, now just summon up the courage and get going!

Just remember your progress meetings. With my own personal modification of OpenAgile, I would end the day with reflections. This gives you a night to mull them over, before you tackle the next day. Then, every morning start your day with your progress meeting. Hit the learning circle and figure out how to learn from your reflections and then look at how you want to change your day. Another great thing about OpenAgile, over Scrum. There is nothing to keep you reaching deep into the backlog, mid-cycle and pulling some task up to the top of the list. Talk about flexibility!

That's it! Yes, there is a lot more to it, but like OpenAgile itself, this is a framework.  A loose  framework to wrap around your own working style. There's a lot you can delve into, a lot you could tweak, a lot you could challenge. So with that, I'll give you one of the last gems of OpenAgile. JUST START! Don't over plan, don't over think, get going and keep going!

Joel BC
Veteran, the Project Manager wars
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.