The Regenerate Web

Brad Egeland has a nice post Cover Your Risk From All Angles. Brad lists Risk Avoidance and Risk Mitigation as two (2) approaches to Risk Handling. While these are legitimate approaches, there is a critical flaw in all these approaches.

When we have identified a risk and a mitigation plan, the execution of that plan occurs when the risk turns into an issue. When the issue is be "handled" there must be budget assigned for this handling. And there must be time in the schedule for executing this "handling" work effort.

Now if the project is disciplined, the Risk Management Budget will be withheld and there will be "margin" in the schedule for this new work.

A Better Approach

In the current mission critical programs we work, the approach is Risk Retirement. This approach identifies the work activities needed to make the Risk go away before it turns into an Issue. This approach can be applied to High Risk items. If these were to turn into Issues, the schedule would likely be impacted.

In less disciplined environments, it is also likely that the budget for the Risk Handling would have been spent. So there is a double impact on the project - you're late and you're over budget.

Think about Risk Retirement for those risks that if they came true would have unfavorable impact.

One of the things I love about blogging is the ability, every once in a while, to stir up some engaging commentary from my readers.  (It seems my Facebook posts do that quite frequently.)  I generally like all blog comments, even from those who disagree with me, as long as they can disagree respectfully.

But recently, my blog has been receiving comments from the dregs of social media: spammers.  Even if they seem like legitimate comments, I really don't want to hear from ViagraGal, WorkfromHome, StudyOnline, BestGamblingSite.  Because of these low-life commenters, I've finally been forced to turn on comment moderation.  GRRRR.  These people want to fill my comment space with irrelevant advertising, so I'm now going to keep them out.

In systems thinking, we talk a lot about inputs, but how often do we discuss filtering out the unwanted inputs?  How do we keep out the crap?  In HR, they do screenings to prevent less-than-desirable hires from reaching the employment status.  In project management, we maintain controls to prevent scope creep from adding to our work.

What about in your job?  What are the undesirable work-turds filling your in-baskets?  What are the safeguards you can use to keep them out?

(And for those who use your real name to comment on my blog with relevant commentary, please be patient with me as I get used to publishing your comments as they appear in my in-box).

Overheard tonight at a restaurant:

Customer: "If I don't like this ______ can I order something else?"

Server: Well, that depends on the manager. Some managers are great about allowing people to change orders if they don't like what they pick. The manager working tonight is IFFy."

First of all, we would hope that our employees would not speak about management like this. We hope that our behind the scenes behaviors would stay behind the scenes. Even so, how does it make this restaurant look? BTW, I am traveling in a small town in middle Ohio (redundant?), so this was a national chain who I assume has standard practices about things like giving refunds to people who don't like their order....

This reminds me of a conversation I had with a group of 12 managers last week where they asked, "how important is consistency and when is consistency important?"

I am all for individual styles and approaches. That said, I think many managers do not fully understand the ramifications of differences in how people are managed and the rules and standards by which they are judged. It is NOT productive to have wildly different performance standards, for example. If you are a tough grader during evaluation time and your peer tends to rate people more favorably, this is a problem and you BOTH are likely in need of adjustment.

Management reverberates and whatever you project will be reflected by your staff. If you and your peers manage differently, these differences will clash at some level. This server was completely unaware that that she was doing something wrong - she should never have revealed that the answer to the customer's question depends on which manager is working. I think she was focused more on her pending tip and honestly, I don't think it would have occurred to her that her response was immature or unprofessional.

I have heard similar comments during recent focus group discussions. Employees who answered a question with, "It depends on who you report to."

When you manage and communicate you fill the workplace with the information that will be shared and acted on by your team. I LOVE it that each manager has a unique style AND I think that some level of consistency is crucial to optimizing performance. It is not safe to assume that your employees have the skills or the motivation to sort things out for you. It is not their job to do so, either.

Thoughts?

My column at Gantthead, The Agile Project Manager: To Facilitate, Serve and Protect is posted. Enjoy!

Tweet This Post

Curtis was very uncomfortable. “You make it sound like I am in big trouble. But isn’t this what management is all about? I mean, aren’t I the one who is supposed to make all the decisions? Aren’t I the one responsible for all the results?”

“You are accountable to your boss for the performance of your team,” I replied. “But between you and your team, it sounds like you are responsible for making up all the plays, calling the plays, taking the snap, throwing the football, catching the football, running for the touchdown. Did you forget to block?”

“Yes, but it’s not that bad.”

“It’s not?” I asked. “Who was here all day last Saturday? How many hours a week have you been putting in?”

“Well, when you put it like that, I was here, 58 hours last week,” Curtis reported.

“And whose fault was that?”

“Well, there was just stuff I couldn’t get done during the week. I have a lot of responsibility.”

“And how much responsibility does your team have?”

In our aerospace and defense domain, a Concept of Operations is a common, and sometimes mandated, document. We rarely see these documents in the commercial domain. But in the commercial world, a ConOps would be a critically important piece of information for the project - for exactly the reason it is critically important for aerospace and defense.

The ConOps describes the "How" in "How to Accomplish the Mission." The Mission in commercial terms can be the business case, the strategy, the Raison d'être for the project.

The ConOps answers these key questions:

• What is the "Mission" to be accomplished?
• What is the intent of the business leaders for this project?
• Who are the key participants in the "Mission?"
• What are the relationships between these key players? The heart of this question is Who's in Charge?
• What resources are needed  for the project to be successful?
• What are the high-level operational tasks that must be performed for the "Mission" to be a success?
• What connectivity is required between the participating system elements? People, Processes, Tools.
• What are the training needs?
• How will we recognize that the results of the project meet the needs of the buyer?

Area 51 is now in beta. This is the promised place where the community comes together to invent new Stack Exchange sites.

Benofsky from Hacker News writes:

Seems overly complicated, I have no idea what's going on when I visit Area 51, I guess this is their strategy for turning away uncommitted users.

Also, how are they going to make money?

I’m glad you asked, benofsky! The answer is simple. Volume.

(transcript)

Well, I’m not one to take Internet chat board comments seriously. After all, the Anonymous Nostradamus’s over at Code Project reacted thus when Stack Overflow itself launched:

I think the UI sucks. I can't imagine this site being around in a year.

We all know how stunningly accurate that prediction was:

Benofsky is onto something, though. Area 51 is not for everyone. If you don’t know what it’s for, or why it’s going to work, or you can’t figure it out, it’s not, actually for you.

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

 So Tony Hayward wants his "life back."

So the pressures of cleaning up BP's disastrous oil spill is too much for him to handle.

So he goes to a prestigious yacht race to cheer on ol' Bob (the name of his yacht).

Big deal... who cares?

Um... well... it would appear... A LOT OF PEOPLE.

On office politics, appearances mean everything.  Arms crossed.  Disengaging in a meeting.  Going to lunch with somebody.  Leaving early.  Arriving late.  Laughing at a joke.  People are paying attention to what you do.  For some of you, you may not care what other people think.  (For the most part, I'm right there with you.)  But, like it or not, we do have to be concerned about perceptions.  If they go unchecked, perceptions can become fact.  And facts can ruin careers.

You don't have to be obsessing about others' opinions every minute of every day.  All I'm saying is to watch out for the ammo you give their perception arsenal.

Curtis shifted in the chair. “But my team never really comes up with anything. Sometimes it seems they just want me to tell them what to do so they don’t have to think.”

“Of course they want you to tell them what to do. If you tell them what to do, then they are not responsible for the solution. All the accountability falls back on you.”

“Yes, but after all, I am the Manager,” Curtis replied.

“It’s a tough assignment to turn down,” I nodded.

“What do you mean?”

“They invite you to take all the responsibility, you get all the glory. It is a tough assignment to turn down. Unfortunately, you cannot hold them accountable for things gone wrong. Your team likes it that way.”

This is why we need a formal Earned Value Management certification process. I don't know how many unsuspecting "Bright Minds" read this, but it is pure nonsense.

How Earned Value is Limited and the Is Your Plan Correct? at Bright Hub, makes claims that are pure bunk.

I love the claims:

• EV works best on smaller, simpler projects
• Getting into technical projects or projects with many tiers can cause the project manager to allow the project to become derailed in the details
• EVM does not tell the whole story on evaluating your project and might not accurately represent what is necessary for a project to achieve specific functionality. But, perhaps most importantly, EVM only covers cost and schedules and, therefore, no quality control is factored into EVM.

The last statement is partially true, but the first 2 lead me to believe that last statement is probably not understood. See if Technical Performance Measures could improve the understanding that Earned Value guidance explicitly states that "Technical Performance" is put of the process - defined in ANSI-748B and the NDIA Earned Value Management Intent Guide.

Lord help us if these types of information sources are actually read by decision makers.

 Been thinking about soul and passion a lot the past few weeks.  I'm a big fan of being passionate... about at least a couple things anyway.  On the longest day (i.e., most sunlight) of the year, it seems we have even more waking hours to be passionate... about something.

But are you letting the sun shine on your passion?  Can people tell what really gets you excited?  Me?  Well, let's put it this way, I could never play poker.  People tend to know exactly how I feel (positively or negatively).  If I'm talking about my kids or my writing or working with the SWAT team, you can barely keep my feet on the ground.  Life is too much of a guessing game as it is.  Why not shed some light on what makes you tick?  Many people, when they know this, are willing to help you out on your journey.

So as the sun sets on the "longest day" make it a point to share your passion with at least one other person.  Who knows where it might lead?  After all, if passion is silent, is it really all that passionate?

"Don't say you don't have enough time. You have exactly the same number of hours per day that were given to Helen Keller, Louis Pasteur, Michelangelo, Leonardo da Vinci, Thomas Jefferson and Albert Einstein."

Borrowed directly from Moj Zarei-Kesheh's face Book page, Thanks Moj

It’s tempting to look for candidates with lots of experience for your open positions. But at this time of year, and through the fall, consider looking for new college grads. Not just because I have a daughter who just graduated, but because new grads offer you an opportunity to steer people without a lot of experience into great employees.

New grads have a huge advantage over experienced people: They don’t know the problem you need solved can’t be solved. They’ve been trained through 4 years of university that all problems can be solved before the end of the semester. They will bring that optimism to work.

Many new grads have worked somewhere, but even those who worked as interns or coops may not have had real professional experience. Back when I was a manager inside organizations, I was able to help new grads find their professionalism.

I have had some trying times as a manager. There was the new developer who thought he could come to work the way he went to school: after 1pm. We had several discussions about core hours. There was the new tester who thought he knew everything, but really didn’t know much about test techniques. I suspect that I was that arrogant when I started, so I had a fair amount of sympathy for him and gave him feedback about how he appeared to me.

I found these experiences, the helping people find their approach to work and their passion rewarding as a manager. I stay in touch with many of them now, many years after they and I moved on.

So, hire experienced people. But don’t forget about people with “no” experience. They may well find new and innovative approaches to your product development. Not because they’ve been trained in the newest techniques, but because they don’t know they can’t do something.

Tweet This Post

A twitter follower asked if I could provide a link to a “discussion of tactical vs strategic planning/projects?” Here you go:

Strategic work is a management role. It involves setting the direction for the organization (or group), deciding what to do and what not to do, who to hire and when. If it involves committing the organization to money in some way, that’s strategic work. Here are some examples (not an exhaustive list): managing the project portfolio, deciding on a product line, deciding when to hire which kinds of people, deciding on a software process initiative.

Project management is mostly tactical, the operational approach to the day-to-day decisions. The one exception is at the beginning of the project, when you decide on release criteria and a life cycle. When you decide on release criteria, you have defined the boundaries of this release, a strategic decision. When you decide on a life cycle, that’s a strategic approach to how you use the people. The rest of a project or a program is tactical. Looking for and managing risks? Tactical. Understanding how people are working together–or not? Tactical. Conducting a meeting? Tactical. Problem-solving? In the context of a project, tactical.

There’s also work that requires tactical time, and is strategic management work. For example: one-on-ones, feedback, coaching, career development/discussion, working across the organization to smooth the way for a project, solve other problems, or accomplish something that managers needs to do, such as collaborating on the project portfolio. This is the day-to-day work of a manager, which makes it tactical. It’s strategic in nature, because it builds culture, retains people, builds a trusting relationship with people across the organization, and implements the mission. I can never tell if this is strategic or tactical.

Strategic work is difficult. It requires thought and discussion. Tactical work is difficult in a different way. Tactical work often demands answers quickly. Strategic work, assuming you don’t postpone it and create management debt should take longer because reflection is a good thing for strategic work.

So when I said in Functional Managers Acting as Scrum Masters: Not a Good Idea that Scrum Masters will do the tactical work postpone the strategic work, I meant that the Scrum Master will conduct the stand-ups, will facilitate the demo, review, and retrospective (maybe not personally), and remove obstacles for the team. That mean no one is thinking about or performing the management work, such as managing the project portfolio or conducting one-on-ones, or solving problems in advance of the team, if the Scrum Master is also the manager.

Let me know if this is not helpful.

Tweet This Post

“What has to happen in the next two hours that will indicate time well spent,” Sam asked. Each person looked around at each of the other members of this management team, then looked down and began to write.

It was not Sam’s intention to figure out the solution to this problem. It was Sam’s intention to have the group figure out the solution to this problem.

The responses from the team were positive.

• We have to agree on the purpose. We have to agree on what we are trying to achieve. We have to agree on the goal.
• We have to agree on what actions we will take. We have to agree on the coordination and interdependencies of those actions. This has to be a period of cooperation.
• We have to agree on what results we are looking for. We have to agree on what measures we will collect and analyze. We have to agree to raise the flag when something doesn’t look right, not to bury our statistics in a warehouse.

Most importantly, this was no longer Sam’s problem. This problem now belonged to the group.

From a recent NDIA (National Defense Industry Association) PMSC (Program Management Systems Committee) meeting - the root causes of project failure

Poor Planning is the Number One Cause of Project Failure

Planning is the filter between the complex, dynamic, and risky “open” systems of the organizational environment and with the “closed” project system (environment).

Project planning must provide structure, while preserving flexibility, especially for those projects involving inventive and/or long term complex work

• Inventive and complex work involves strong elements of discovery, and requirements tend to emerge and evolve as the project evolves
• It is often not possible to determine precise answers and create detailed plans.

(We) Need ways to “respond” to change and evolving innovations Project planning must balance emphasis on project goals with capability (existing resources and knowledge) takes shape

Mike Griffith's has got me thinking about PMBOK®, the Agile software development processes and a general notion of "what to do." Alec Satin has a nice "electronic book" of 72 tips for project managers. Please subscribe for some useful information.

Anyway, I've got an idea to move the several decades of experience, ideas, and actual beneficial outcomes into a book like Alec's. Here's the outline...

Now I don't have experience in all these areas. But I do have deep experience in some. So I'm going to start collecting advice from the 3 dozen or so notebooks I've filled.

Along the way, it'd be interesting to see how agile software processes can be connected as well. By connected I mean practical, field proven activities that "answer the mail" (as we say in the defense proposal business).

My personal experience is focused on building the Performance Measurement Baseline (PMB), performance measurement processes (Earned Value), programmatic and technical risk management, the ubiquitous Work Breakdown Structure (WBS), and the programmatic architecture represented by the Integrated Master Plan and Integrated Master Schedule, the measures of increasing maturity, Measures of Effectiveness, Measures of Performance (MoP), and Technical Performance Measures (TPM).

I'll make an effort to add to the list every week and store this "map" and the information on the www.niwotridge.com site.

Rarely, if ever, is the conversation around agile and its relation with project management processes set in a domain and a context in that domain. It's time to reset the conversation with the just those items. To establish the "rules of engagement" for the conversation.

• When we say Project Management what do we mean?
• When we say agile, in what domain and context are we speaking about?
• When we say anything about anything, what is the domain and context?

The discussion around PMBOK and agile first needs clarity. PMBOK is a set of principles (of sort) that can be applied to a wide variety of project domains and contexts within those domains. It is agnostic about "how" these principles are executed.

For example, 5.2 Define Scope, says

Define Scope is the process of developing a detailed description of the project and product. The preparation of a detailed project scope statement is critical to project success and builds upon the major deliverables, assumptions, and constraints that are documented during project initiation. During planning, the project scope is defined and described with greater specificity as more information about the project is known. Existing risks, assumptions, and constraints are analyzed for completeness; additional risks, assumptions, and constraints are added as necessary.

There Inputs, Processes, and Outputs for Defining Scope. This "clip" is from PMBOK.

Now if an agile software development process - say Scrum - has artifacts or process steps that can be mapped to this process flow - great.

But Here's the Rub In The Discussion

The starting point in the PMBOK and Agile discussion is PMBOK. The Guide to the Project Management Body of Knowledge®. Not the other way around. Or at least not the other way around from my point of view.

So when Mike Griffith s makes a nice map from PMBOK to Agile, we're starting to connect the dots. But here's the rub.

That map - the connection of the dots - is context and domain sensitive. That is the practices that are connected to the principles of PMBOK has a domain - software development, and a context - agile software development team, with all the associated attributes of a software development project using agile.

This is all fine and good, but without stating the Domain and Context it might be seen as a replacement for the principles of PMBOK®

This is not normally the case, but it needs to be said upfront. In the proposal business and on program execution, we use a term - "rules of engagement." How are we going to engage each other in conversation? Essentially what is the domain and context in that domain for moving forward with our work?

Hello beloved blog readers. I am sorry I have not given you much on this blog recently. No excuses, I have chosen to focus on finishing the senior leadership book I am writing (due June 30!) and have been doing many client projects. When it rains it pours, right?

I am putting the finishing touches on a chapter in the new book called They are All Moments of Truth. If you are "sage" like me, you might remember a book from Jan Carlzon in the late 80s called Moments of Truth. Here are three great quotes from that book:

“Last year each of our ten million customers came in contact with approximately five SAS employees, and this contact lasted an average of 15 seconds each time. The SAS is ‘created’ 50 million times a year, 15 seconds at a time. These 50 million ‘moments of truth’ are the moments that ultimately determine whether SAS will succeed or fail as a company. They are the moments when we must prove to our customers that SAS is their best alternative.”

"Mistakes can usually be corrected later; the time that is lost in not making a decision can never be retrieved”

"... the right to make mistakes is not equivalent to the right to be incompetent, especially not as a manager."

The point of this chapter is that leaders need to think of every moment as a moment of truth. They have less time to spend with each individual they meet and must build rapport, relationships, and trust quickly and well. The higher you go up the corporate food chain, the more quickly you need to build credibility. Every conversation, greeting at the company picnic, speech, and email is a moment of truth and precious.