The Regenerate Web

I was reading, Nervous about an interview? Try this! and thought, hmm, I’ve said something like that before, haven’t I?

I have, but in slides (for my Hiring for an Agile Team tutorial and workshop and in my other workshops) and in person, but not on this blog. So, let me say it here:

Good interviews are conversations. Period.

Good interviews do not surprise people. Good interviews build rapport with a candidate, learn about a candidate, preferably with behavior-description questions and auditions. Maybe with hypothetical questions. Maybe with a meta-question.

But good interviews should make a candidate (and an interviewer) think, not sweat.

Tweet This Post

Miriam crept into the conference room so as not to disturb the rest of the meeting. Everyone was working hard on their business plan for 2010. "I'm having a bit of trouble," she said. "I know all the steps for the plan, but I am just stuck."

"What have you done so far?" I asked.

"Step one was the purpose. We know the focus for the project, what problems it is supposed to solve. Then, I created the vision. And that was easy. I think I got it all captured in a couple of sentences. It's the rest of the plan that I am having difficulty with."

"Interesting," I replied, "that you can capture the detail of your vision in two sentences."

"Well, you are right," Miriam confessed. "There isn't a lot of detail, but I thought it would be better if it was short."

"Miriam, here is the way the vision part of the plan works. The more detailed it is, the clearer the images are, the easier it is to write the rest of the plan. Instead of two sentences, write two pages. I want to know who your customers are and what services you provide. You probably have more than one customer segment, tell me how they are different and how your services to each are different? Tell me what position you hold in the marketplace, what your market share is? Who are your competitors? Tell me what your competitive advantage is, what are your core competencies? Who are your key personnel, how do you find them, how do you grow them? Tell me about your facilities, your plant? How do you control quality? How do you guarantee performance?"

Maybe it was a byproduct of too much togetherness over Christmas break.  Perhaps it was caused by a decade of being outnumbered by the fairer gender around home.  Could have been too much eggnog.  Who knows?

My younger daughter got a new Barbie dollhouse from Santa.  So of course, every Barbie had to come and inhabit this new abode.  It was like big plastic sorority (complete with all of the requisite drama whenever that many Barbies get together).  And - oh yeah - there was one Ken doll amid all of them.  All was well.  The girls were playing together.  They were having fun.  They were using their imaginations.  And then the fateful event occurred:  my older daughter asked my younger daughter for the Ken doll:  "Abby, would you please pass me the boy Barbie?"

I snapped.

"Excuse me?" I started.  "Did you just call him a 'boy Barbie'?  His... name... is... KEN!  Yes, he may be the ONLY boy in a sea of plastic estrogen... BUT HE HAS A NAME!!!  HE HAS AN IDENTITY!!  He is NOT a boy Barbie.  He has NOT been sucked into the vortex of pink."

I found three pairs of eyes staring at me in shock at my tirade.  I shrugged and went back to my little cubbie of testosterone, my small corner of maleness.

In a sea of consistency and sameness, we all have a little bit of Ken in us, don't we?  We all have a personal brand just waiting to get out, but everybody else wants us to wear their personal brand.  We want to convert our gray cubicles into a tropical rainforest.  We want to wear brightly colored polka-dots in a sea of navy blue pinstripes.  We long to be different, to be significant, to be noticed.  In short, we cringe at the thought of being called a "boy Barbie."

So what are YOU going to do in 2010 to brand yourself?  Or are you just another boy Barbie?

"We need to put a plan together," Karlyn declared. "Let's meet in the conference room and set some goals."

"Sounds great," I replied. "But what are you going to set the goals for? I need to know a few things before we get to setting goals."

"Like what?" she pushed back.

"Karlyn, do you remember that multi-track project last summer. You had five teams working on simultaneous tasks for two months. In the end, you were missing two major pieces, but you had used up all your budget. Two of the teams went off on a tangent and created stuff that turned out to be useless."

Karlyn went silent. "I was lucky I didn't get fired over that one," she finally admitted.

"What went wrong?" I asked.

"We never clearly understood the purpose of the project and spent a lot of time and money on things that didn't matter."

"And why didn't you understand the purpose of the project?" I pushed.

"I guess we were moving so fast that we didn't stop and ask. We knew it was a fast track project with tight deadlines, but we didn't go slow enough to make sure everything we did was necessary."

"And how do you know if something is necessary?"

"That's why we have to define the purpose for the project. Before we can set goals, we have to make sure we understand the purpose."

The past 2-3 years have been spent fretting.  People have been worried about their jobs, about their companies, about their stability.  Business owners have sweat bullets every night, wondering if tomorrow would be the day they had to shut the doors for good.  Many have continued to do business in good faith, even with the evil thumb of fate hanging immediately over them... waiting to squish them like an insignificant bug.

Other companies have managed to ride out the storm, but they've not played nicely in the corporate karma sandbox.  They've taken advantage of suppliers and contractors.  They've oppressed employees.  They've screwed over customers.  Here in Central Iowa, there are a couple of companies who have low-balled project management consulting rates to insulting levels.  Why?  Because they know supply outstrips demand.  There are companies who have all but expressed they don't care if they lose a customer... there will be another to take their place.

But...

Recovery is coming.  The economy is showing some signs of rebound.  While it may not happen tomorrow, companies are looking like they'll be hiring, doing more projects, and expanding their businesses... it's a cautious recovery, but it's a recovery all the same.  And what's going to happen when all of these "you done me wrong" vibes come to light?

Jeannine Aversa wrote a great piece today that job satisfaction is at an all-time low.  It's harboring ill-will, impacting teamwork, and undermining culture.  I've been fortunate to work for clients who have risen above the pettiness and have been great.  I have also had the luxury of recognizing the other end of the spectrum and be able to politely decline my services.  Some of my local colleagues have not been so fortunate.

Is your company ready to compete in a stronger workplace?  How do your employees really feel about you?  Are your suppliers and customers loyal to you through thick and thin?  If the responses to these questions are not all that positive, recession survival may be the least of your worries.  Your system's feedback loop is about to catch up with you during the recovery.

The NAVAIR Earned Value Management Tool Kit - available at the Defense Acquisition University web site. (When you reach this site, answer yes to the missing certificate)This site by the way has a wealth of resources for everything related to program management. If you're looking for something, start there.

Here's NAVAIR's restatement of the obvious.

NAVAIR EVM Guidance For Success And Failure Of Projects

Successful Projects

Failing Projects

?  Effective project planning

?  Inadequate project planning

?  Effective project cost estimating

?  Inadequate Effective project cost estimating

?  Effective project measurements

?  Inadequate Effective project measurements

?  Effective project milestone tracking

?  Inadequate Effective project milestone tracking

?  Effective project quality control

?  Inadequate Effective project quality control

?  Effective project change management

?  Ineffective project change management

?  Effective development processes

?  Ineffective development processes

?  Effective communications

?  Ineffective communications

?  Capable project managers

?  Inexperienced project managers

?  Capable technical personnel

?  Inexperienced technical personnel

?  Significant use of specialists

?  Generalists rather than specialists

?  Substantial volume of reusable material

?  Little or no reuse of technical material

Like all restatement of the obvious, many things are not so obvious.But notice the emphasis on Planning, Cost Estimating, Performance Measures, Quality, and Change Management. All activities that cause project churn. Even in the best of agile development, if the goal of the project keeps changing, and the agile team rapidly responds to these changes, money is being burned for work that may or may not be recoverable.

This is a fundamental "hidden cost" of poorly defined agile projects in the same way it is for poorly defined traditional projects.

If I create work product that is then tossed, it is a non-recoverable sunk cost

So ask these questions for your project, no matter the method used. And ask anyone who brings you a technology solution to your project - How does you new technology improve the probability of success?

If you notice in the NAVAIR table, people and processes dominate the conversation. Tools are a distant third.

Lots of response to this morning's blog post about My 2010 Business Plan, our current Subject Area at Working Leadership Online.

Sometimes as Managers, we talk out of both sides of our mouth. We understand the benefits of planning, but we also have a litany of excuses why we don't plan more often. Over the last 15 years, we have created a bullet-proof planning model that blows away the excuses. And if you are willing to do the work, we will share this model with you for FREE.

If you have a manager (or if that manager is YOU), that would benefit from using this process, follow this link to get a Free Trial to Working Leadership Online.

Your Free Trial membership is good through January 31, 2010. It includes full access to our online learning platform. In this Subject Area, you will:

• Understand why planning is important and where it can be useful.
• Understand what prevents us from planning more often.
• Understand a model of planning that helps us be more effective in planning.
• Create a 2010 Business Plan.

We are holding only a limited number of slots for this Free Trial. Looking forward to seeing you online.

I am putting the finishing touches on my next book, tentatively called Coaching Up and Down the Generations. One of the things I have always struggled with is what to call the person who is being coached. Each company I have worked with and for has had a different name. Sometimes these learners are called proteges or coachees and if we are talking about mentoring, then the person might be called a mentee.

These names all seem so patronizing to me and tend to reinforce that the coach and mentor is the one who "knows," like a mountain-top guru. And while there is a time for sharing sage advice, I would like the overall focus to be on the goals and interests of the person being coached. And we know that often the best coaching comes in the form of a question, not an answer.

For this book, I decided to call the person who is receiving coaching a performer. The person who seeks coaching has a goal and when he/she moves forward toward that goal, he/she performs. This makes sense to me and I like that it puts the focus where it belongs. And if I could rename the coach, I would call him/her a helper, because this reduces the guru aspect of coaching and reinforces the service oriented nature of good coaching.

What do you think? Have you heard of a name that is even better than "performer?" Do tell!

From Working Leadership Online.

In our most recent Field Work assignment, we are working on My 2010 Business Plan. Part of the work is creating the plan. The other part is the conversations around the plan.

Question:
This is going to be a tough assignment. We are just a division of a larger parent company that doesn’t have a digestible business plan to subordinate our plans to.

Response:
The fact that your parent company does not have a digestible plan is not unusual. And it does make it tough to understand the context for your plan. And that's the point, to examine these deficiencies and make some improvement. If you are the only person in the company to create a plan for your team inside of a department inside of a division inside of a parent company, then we have made one small step toward improvement. And the biggest result of this planning effort will be in your team and your department. And YOU will be a more effective manager for it.

One thing my clients sometimes ask me to do is help them improve their processes.  I've done it for banks and for factories (and all with no Six Sigma blackbelt).  You can't improve a process, however, if you can't document the process.  I liken it to attempting to take a trip to an unknown location with no map.  (And don't ask my sister-in-law... all of her directions are subjectively obscure landmarks... "drive to the mall, then turn left until you hit the pumpkin-colored house... no, not the tangerine-colored house... anyway, then drive until you find the barn with the three pretty dogs..." Well, you get the idea.)  No, my friends, a roadmap (or GPS) will get you from Point A to Point B.

At a minimum, I like to create a deployment (or swimlane) flowchart.  Unlike a "generic" flowchart, the swimlanes show who is responsible for completing each task in the process.  If you understand the process of making a flowchart, this is very telling for either existing (as is) processes or desired future (to be) processes.  And yes, I am a big fan of documenting both your existing and future processes.  Most people don't want to "waste" time documenting the existing processes, but doing so helps you flesh out many of the potential areas for improvement.

The process for creating a flowchart is really an offer you can't refuse... and yes, the Godfather reference is intended... it will help you remember HOW to build one of these bad boys:  BRANDO

B is for Boundaries - where does your process start and end?  If your process is really big and complicated, consider breaking it down to smaller processes.  The oval is the tool to show the start and finish of each process.

R is for Roles - who are the people working on your process (not specific names, but more job titles or role definitions.  I tend to list them in the order they are introduced into the process

A is for Actions - identify the individual steps in the process.  Tasks go into rectangles and decisions to into diamond shapes

N is for Negotiate - discuss and clarify and validate the steps.  Be prepared to argue and debate and edit and change so that everyone is in agreement (and no, not everybody currently does the same process the same way)

D is for Draw - connect the lines among the rectangles and diamonds, add any supporting documentation to show paperwork or computer interactions

O is for Opportunities - look at the existing process to identify areas for improvement and then brainstorm for solutions to improve the process (or maybe decide the process isn't even needed at all)

Of course, I spell all of this out in SWAT - Seize the Accomplishment, and you get to follow along as the characters struggle with all of the "yeah, but what if" twists and turns in their quest to do it right.  In the end, though, you will see that a well-drawn flowchart really is "an offer you can't refuse."

Josh Nankivel has a nice thread going on his PMStudent blog about risk management. There's the usual number of responses from a variety of points of view. I'd like to make an important point from my personal experience in the risk management business on programs where improper managing of risk gets people killed and wastes billions in public funds.

Not all risk management approaches are equally credible

That's not to say these approaches aren't useful in the domain in which they are applied. Doing risk management on an ERP project. Doing risk management on a road paving project. Or maybe in Josh's notional example, doing risk management on the winter drive to the relatives.

But here's the problem with home grown risk management processes - as well as home grown processes for building a WBS, installing an EV management system, performing requirements management, writing proposals for FAR compliant procurements, conducting project performance measurement assessment, and a variety of other project and program management process areas.

There is a way of doing the work that gets you by in the domain in which you work.It's good enough.

"We do it this way in our world out here in the boondocks and it's worked for us, so it is likely it'll work for you as well."

And then there is a way of doing the work that follows a set of immutable principles.Principles developed over time in a variety of domains that are independent of the personnel apply them.

As one of our nieces is fond of saying to her advertising clients when they come up with their own ideas of how to write and place spots, when they say "we've go a great idea from a competitor, do you like this? "Ah, no so much" is her usual response.

So Here's Some Advice from a Program Manager on High Risk Programs

If you’d like to start a conversation about risk management, I’d suggest you look into the sources of guidance used by those working “high risk” projects. NASA, DOE, and DoD. I say this from my hands on experience of writing and executing Risk Management Plans (RMP) in nuclear power and weapons, manned space flight, and other DoD domains. While the PMI approach is an OK starting point, SEI’s Continuous Risk Management is a better of guidance for the software development world.

Next take a look at “The Death of Risk Management,” to see how we’ve dumbed down the application of risk management in many domains. As stated on the title page, the author is the Chief Engineer of NAVAIR. Each service has a CE, he’s the one accountable for all things that fly for the NAVY. Page 4 of that presentation speaks to the misunderstandings of many risk management situations.

On the web The Risk Doctor is a pretty good place to start. However, the notions he uses of combining risk and opportunity are highly domain dependent. In the domain where things blow up and kill people, mixing them is usually limited to the early design stages. For a quick overview of the principles of Risk Management.

For some historical background on the application of risk management read Disasters and Accidents in Manned Space Flight, David Shayler, Springer / Praxis. There are many other books, most bad, many other opinions, most untested in domains where people die or billion are lost with a single mistake. The one book to own (other than the SEI CRM handbook which you can find on the web), is Edmund Conrow’s Effective Risk Management: Some Keys to Success, 2nd Edition, AIAA Press, 2003.

For the “execution“ of the Risk Management Plan, see the Mitre framework for useful guidance. The Mitre approach is used on many programs we work. As well see the DOE 413.3 series and the Risk Management Guide for construction and high risk product based projects.

Finally it is critical to separate programmatic risk from technical risk – although technical risk does drove programmatic risks. See DID 81650 for guidance on programmatic risk assessment.

First, the risk mitigation or retirement activities MUST be embedded in the Integrated Master Schedule, with funding and resources held in escrow. What happens in the traditional approach is when the risk becomes an issue; you usually don’t have any money or resources. So you’re both late and over budget. The better approach is to RETIRE the risk during the execution of the program. When the risk becomes an Issue, normal project execution processes apply and the addressing of the issue becomes a work package management process with normal cost, schedule, and technical performance processes.

My final advice for guidance – as a practicing programmatic and technical risk manager on two high risk programs – is to NOT make up your own version of how to do things or to dumb down the definitions; adjust them for domains; or other similar simplifying approaches. This dilutes the practice and usefulness of RM. Instead look at the official guidance from DoD and DOE found at the Defense Acquisition University.

Now for a Practical Example

Risk – like the car accident example Josh speaks to – on the program are things we have no real control over, other than preparing as best as possible for the probabilistic arrival. For example a “flying machine,” can crash for a possibly unknown reason. It will be known after the crash of course, but at 1st flight test, it was not. The Flight Readiness Review (FRR) will have considered all risks to the 1st flight and either mitigated them or retired them prior to the FRR. Now along the way, we identify potential causes of a crash and either retire them, mitigate them, or ignore them. The transfer option is not possible, since the client is the system integrator and the “buck stops there.”

The benefit of this approach is it separates the risk responses into – true “risk” and “risks we can do something about.”

For the winter driving example it is prudent have in your car all the “risk response” materials. Blankets, fire starter, emergency radio, etc. etc. Where the accident situation can’t carry all the response materials – like another car. The “handle-able” risks must be in the Integrated Master Schedule. We know they are risks and we know how to perform risks handling on them – one of the four responses. It’s the ones that we have no pre-defined response for that are the real “risk” to the program. This allows risk management to focus on the “real” risks and systems engineering and program management to focus on the risks that can be handled.

The December Harvard Business Review has an article, Is the Rookie Ready? (You have to subscribe and pay to read the whole thing.) The story is this: Kristen is the new project manager, reporting to Tim. The old PM left because Tim, who’d been her manager for 6 months didn’t know how to work with her. Tim hears from an old customer two weeks before Christmas, “Please help us and send a team down to install your software, the stuff we rejected a year ago because it was too expensive. Oh, and we need it by Jan 1.”

Tim agrees (Big Red Flag here). He asks Kristen to go install and make the standard software work (no customizations) and to take whomever she needs. Kristen doesn’t think this is a such a good idea, but Tim tells her it’s her job to make it happen. He tells her to tell the team ‘we’re going to do this.’

The question to the famous commentators is, “Is the Rookie Ready?”

Wrong question. Michael Schrage suggests hiring back the old PM. But, then he says “Kristen is in over her head.”  NO. KRISTEN IS NOT IN OVER HER HEAD. TIM IS A TERRIBLE MANAGER. We can’t tell if Kristen is in over her head.

Sorry for yelling, but I just couldn’t take it. (You should have heard me while I was reading the article :-) Anyone would be in over his or her head, because the only way to solve this problem is to have someone intimate with the product install it. Even then, this is a 6-week project. Why would Tim agree to a 2-week install? Sure, the customer wants it. Customers want all kinds of things. They can’t always get what they want, when they want, for the price they want.

Tim is a terrible manager, because he keeps taking the best programmers and making them managers (part of the story I didn’t summarize). If they want to be managers, that’s fine. But it’s not clear Kristen wants to be a manager. And, he doesn’t even push back on the customer. And, Tim has allowed a standard product without a standard install.  (Ok, it’s a big product. Maybe a standard, unattended install isn’t possible. Maybe it really does need 6 weeks to install. So, why isn’t there an install group that does this??)

Why would Tim agree to do a special install over the holidays without asking for more money? Why would Tim even think this is acceptable to do without asking the team who will do it? Because Tim isn’t the one giving up his vacation. The fact that he even thinks this is acceptable behavior just astonishes me.

It’s time to ask if this project is strategic to the company. (Where are all the other managers? Why is Tim getting this call? HBR, I can write a more realistic story than this.) Maybe this is not even a project to take on.

If they’d asked me to comment on this story, here’s what I would suggest:

1. Decide if the project is strategic to the organization. Why has the customer changed their mind on what’s too expensive? What is an acceptable fee for doing this project in their time frame?
2. At the same time, before committing anything to the customer, ask the team if they are willing to make this happen in the requested time frame. If not, what is an acceptable time frame? Would that time frame change if they had the experienced project manager back? What would make the time frame decrease?
3. If the project is strategically important, and the team is ready to commit to something, negotiate that with the customer. Never assume it’s fine to commit your team to work they haven’t committed to.
4. Organize timeboxes of work starting now and through the final deliverable, so there is transparency about the project’s progress. If the project falters, you still have the option of getting the experienced PM back and see if that makes a difference.

Tim is creating management debt by making bad decisions. He’s not managing the project portfolio–what other projects are now crises? He’s not managing the people. He’s certainly not building a trusting relationship with his people. What the heck is he doing?

I’m so worked up about this because I worked for a jerk like this once. He committed all kinds of deliverables on behalf of my project to the customer. Half the time, he didn’t even tell me. He never once thought what was good for the organization or even the customer.

Managers like Tim kill an organization. They create management debt by not managing people correctly, by not managing the project portfolio correctly, and by not managing the customer correctly.

The question is not whether the rookie is ready. As Paul Muller, one of the experts who commented said, “Every manager has a first crisis, whether it’s three days or three years after assuming the role.”

The question is not “Is the rookie ready?” The question is why is Tim employed at the organization? Why has no one seen the messes he has made?

Tweet This Post

I asked Ellyn to create a list of reasons why planning might be important to her team. Here's her list -

• We are more efficient when we plan.
• We can use planning to set effective goals.
• Planning gets everyone on the same page.
• Planning helps us explore contingencies.

So, I asked her why she didn't plan more often. It took a few long seconds as she sank back in her chair.

"You know," she started, nodding her head, "sometimes it just doesn't seem to be worth the trouble. So, here's my list for that.

• We have too many other emergencies to deal with today.
• We can't get everyone together, schedules are too difficult.
• Even if we plan it, things never work out that way, anyway, why plan?"

So, what's your list. What gets in your way of planning?

I’ve been talking with a colleague who is looking for a job. He’s comparing two senior engineering jobs.

At one interview, it was clear that the manager makes all the technical decisions. No, the manager doesn’t code anymore; he makes all the technical decisions though, for a 12-person group.

At the other job, it looked as if my colleague might be the most senior person there. The other folks are young and smart, but just don’t appear to have the same amount of experience he has.

I asked him who he would learn from, at each job. He immediately answered the job with the younger group. Why? Because the manager in the first job would prevent him from learning.

He said something like this (I’m paraphrasing), “When managers don’t manage, and make all the technical decisions, they make it harder for the team to grow and for people to learn.”

So hiring managers, remember, the interview works both ways.

Tweet This Post