The McCarthy Show Blog

Project Management and The Core: Intentional Development Protocol Part I

michele@mccarthy.net — Sun, 11 Dec 2005 14:00:00 GMT

This topic is a BIG ONE. I wrote the first two essays just so I could establish the necessary background for writing this essay.

I call this idea schedule crunching.

The Conventional Approach

I think it is common to take a more conventional project management approach and concentrate on sticking to the plan, sticking to the schedule, and slipping when something goes awry. The assumption is, typically, that problems are out of the team’s control and, therefore, problems are sufficient reason to slip the schedule. Since there are so many problems that arise on a project, there are typically many slips as well.

Many wise people have said that what you put your attention on is what you will create around you. This is true in project management. If you concentrate on meeting the plan and slipping when big problems arise, you will, at best, ship on time, and more likely, you will ship late.

Schedule Crunching

I want to advocate a different way of thinking about time on a project, the anti-slip, crunching the schedule. This is when you do everything in your power to not only prevent slips but bring the schedule in early as much as possible. You want to ship as early as possible. Envision crunching your schedule like stepping on an aluminum can.

To change your results by changing the way you look at how your team uses time, you must put your attention on how to make tasks take the least time possible. Replace “sticking to the plan” with “looking for ways to decrease the time spent.”

Be Proactive

When I made this shift in my own head about 13 years ago, I noticed that it felt more proactive. Instead of sitting back and waiting for things to happen as I had done in the past, I became an investigator and a leader. I became vigilant about what might take a lot of time on the project and led the effort to tackle it as soon as possible. I was constantly investigating people on the team or people our team was dependent on to look for “gotchas.” It might sound tiring, but it wasn’t. It was a lot more fun. I quickly noticed the power this approach gave to the team. We became creators of our own destiny.

Creating Time

We talk on our team about creating time. It is common to view time as being in short supply. We believe that if you apply human intellect, especially a multi-personal intellect to the problem of how to create time, that there is plenty of time. As you would guess, creating time can be very helpful in shipping products on time and early. Creating time is not magic, although it feels like it. You can create time on your team by adopting a better idea, an idea that takes less time.

Creating Real Buffer

I believe that when teams concentrate on shipping as early as possible, they create real buffers. I don’t think just sticking huge amounts of time into a Microsoft Project schedule is an effective way to buffer a project. True buffer time is created by a team when it is constantly looking for ways to create time, to move features to the next version, to implement big ideas that solve hundreds of problems with one insight. When the team is proactively crunching its schedule, then it is creating buffer for itself.

There are two reasons for this. When the team takes as little time as possible to implement tasks it will have more time to deal with unforeseen problems. The more important reason is that a team that attacks its projects proactively is practiced at dealing with change. That’s the best kind of buffer. A team that can adapt quickly and efficiently to new stimulus is optimally “buffered.”

What You Can Do

The first place to look for opportunities to crunch the schedule is the biggest block. Begin there and ask yourself and your team “How do we do this faster? What help can we ask for to get this done tomorrow?” Then continue down from there. What’s the next biggest block? How can you get that done faster?

When you are receptive, opportunities to crunch will start appearing all around you. Using the Investigate Protocol(see http://www.mccarthy-tech.com/thecore1_5.pdf), you will find many ways that your team can create time. For example, look for things the team is “waiting” for. If someone is waiting, that is always an opportunity to crunch the schedule.

If you think you’ve gone through every aspect of the team’s work and found every possible way to create time, start over. Go through the exercise again and look for new ways.

And again, don’t look just at tasks. Look at everything. Some people, for example, go down to about 5% productivity when they are tired(I am a good example of this). You don’t want those people working when they are tired. They are wasting time. You’d be much better off if they spent that time resting. You’d get a 20X productivity gain if they rested.(See Power Sleep by James Maas) As another example, some people will let themselves be constantly interrupted with phone and email. That’s easy to fix if you have the intention of changing it.

Keep your Core Commitments. If you use CoreCom, you are committed to implement the best idea at all times. The best idea will rarely be the conventional idea. And one of the best ideas I’ve found so far for being on time is to get the work on your project done as fast as possible rather than according to schedule.

Project Management with The Core: Rule #3 Crunch the Schedule

michele@mccarthy.net — Sun, 11 Dec 2005 14:00:00 GMT

This topic is a BIG ONE. I wrote the first two essays just so I could establish the necessary background for writing this essay.

I call this idea schedule crunching.

The Conventional Approach

Schedule Crunching

Be Proactive

Creating Time

Creating Real Buffer

What You Can Do

If you think you’ve gone through every aspect of the team’s work and found every possible way to create time, start over. Go through the exercise again and look for new ways.

Project Management with The Core: Rule #2 Figure Out What's Blocking You

michele@mccarthy.net — Sun, 11 Dec 2005 14:00:00 GMT

One of the best ways to make sure your project team maximizes efficiency and ships on time is to figure out the project “blocks.” In other words, answer the question “What’s blocking you?”

You might recognize this question from the Personal Alignment pattern and protocol. Figuring out what’s blocking you as an individual is essential to getting what you want, your personal alignment. Figuring out what’s blocking your team is essential to shipping great products on time.

When I ask a team “What’s the biggest block?” I’m talking about the most interesting block, the most daunting one. Another way I ask that question is “What is the biggest block to shipping this product tomorrow? Why can’t that be done?”

The Critical Path
There is a project management term called the Critical Path. This means that if you were to map out all the tasks that need to get done to ship the product, noting all dependencies, the longest chain of tasks is the critical path. It is the path of most resistance. It is why the ship date is as far out as it is.

When you ask yourself “What’s the biggest block?” you are usually going to come up with some task or chain of tasks, the critical path. However, when I ask about blocks, I’m not just referring to tasks. Sometimes the biggest block is something else, such as low morale, team exhaustion, “waiting” for a reorg, distraction with a budgeting task, missing a key team member, fighting between team members, etc. When doing this exercise, do not limit yourself to tasks. Everything is important. It is important to be truthful with yourself and with each other. What is really the biggest block?

(As an aside, it’s interesting that if the biggest block turns out to be something psychological like waiting for a reorg, the prescription for success is almost always to go back to the tasks. In other words, even though the biggest block isn’t a task, the solution to the block is getting the team’s attention back on the critical path tasks.)

In a Meeting
Asking “What’s the biggest block?” or getting alignment around that question is almost always a great way to run a project meeting. When running the Meet Protocol(see Files section in TheCoreProtocols yahoogroup), if you don’t have something specific you want, just default to “I want us to align around what the biggest block is.” or “I want to understand what the biggest block is.”

Typically, the biggest block moves around. It changes over time. In other words, it is useful to ask yourself this question every day. It is useful to ask your team this question at least once a week.

Investigate Your Team
Everything you need is on your team. It is important that you don’t decide independently what the biggest blocks are without team alignment. It is almost a sure thing that your fellow team member holds some crucial piece of information about the biggest block that you weren’t even aware of. What’s scary is that he maybe isn’t even aware of it. The way to get that information out in the open where you can do something about it is to investigate your teammates.

Investigatory Questions:
What do you think is the biggest block?
What help could you/we ask for to get that done?
How can we do that faster?
What’s keeping us from shipping this next week?
Do you think that is one of the biggest blocks or the biggest block for the project?
Joe, do you agree with that?
Sue, what do you think?
So, I’m hearing that the biggest block is receiving the new piece of equipment from Acme Corp. Is that right?
Can we drop this feature for this version?
How can we not do this task?
Have we considered other options for solving this problem?
Have we asked for help from the best sources of help possible?

Block Shame
Once in a while I’ll run into a team that doesn’t want to discuss the biggest block because one or more team members believe it is shameful to discuss. For instance, they might feel if you say one task is a block then you are blaming or shaming the people associated with that task. At that point, it is important to back up and define what you mean by the terms “critical path” or “block.” Get alignment on your definitions and then proceed. You can diagnose block shame by the symptoms of defensiveness and unwillingness to answer the investigatory questions.

Those symptoms would also be symptoms of an unaligned team. If you are working with a team that is not “booted” and does not share the Core Commitments(see http://www.mccarthy-tech.com/thecore1_5.pdf), getting through this discussion might be a lot more difficult because of a possible lack of trust, respect or shared vision.

An Obstacle Course
Pretend that your project completion is an obstacle course and you want to get the biggest obstacles over with in the beginning. Here are some strategies for being on time or early:

*You want to know what all the obstacles are as soon as possible.

*You want to deal with the biggest, hardest obstacles first.

*You want to complete every obstacle as soon as possible, rather than “on schedule.”

*If you can go around an obstacle or skip it, do that.

*Your team has to stay on the same course. You don’t want part of the team on a different course.

*Getting your team aligned about the blocks and how to deal with them using the entire team IQ is much more efficient than “working hard” or pounding away at the problem. Look for the big ideas.

*Make sure team members aren’t going over obstacles that don’t exist.

*What’s the biggest obstacle? Get that done. What’s the next biggest? Get that done. Repeat.

Family and The Core - 100% Trust

michele@mccarthy.net — Sun, 11 Dec 2005 14:00:00 GMT

Some of the issues The Core deals with are:

What do you want?
What is your intention?
the virtue of Trust
Creating Connection
investigating
accountability

This idea incorporates all of those. One idea I’ve been trying with increasing clarity and success is intentionally seeking 100% trust with my children. I’ve decided I want them to trust me 100%. One daughter is 11 and one daughter is 9.

The main way I do this is to tell them “I want you to trust me 100%. So what will it take to get us there? What do I have to do?”

Then I really make sure I understand what they are afraid of and figure out a way to resolve it.

Perhaps they are afraid of something real. For instance, one daughter said she was afraid I would call her a name because she had seen me call Jim a name 3 years ago. I resolved it, for now, by telling her that I had changed and explained that is why it had been so long since she had seen that happen. I also asked her what it would take for her to change her mind….what it would take for her to trust that I had changed and I wouldn’t call her a name. She said she thought she would just change her mind.

Sometimes I have noticed a kid is afraid of something happening that has never happened. So, I ask her when she remembers that happening and she says never. So then I investigate how she fears something that hasn’t happened and what it would take for her to trust it won’t happen.

Of course, there could be the case of them fearing something that could happen, such as a death or injury or other trauma. I haven’t personally had to deal with this one very much. In small cases I have dealt with it by empathizing and reminding them of how many great adults they have in their lives to take care of them.

I can also imagine the case where the child will bring up a reasonable criticism of the parent. For instance, if I hadn’t already changed my name-calling behavior, I would have to change it now in order to gain my daughter’s trust. A small price I think.

I have noticed that I have had to be consistent with this agenda. The first times I asked, they weren’t 100% forthcoming with their fears or criticisms. They would say silly things, at first, to test the waters. They wanted to make sure it was truly safe to say what they thought I should improve on.

One other thing I do is I keep my antennae out for signals of mistrust. When I hear any clue that they have mistrust for me I make sure to wrestle it to the ground. “Why don’t you want to talk to me when that happens? Is there something I could do to make you trust me more? I want your trust. What do I need to do?”

When I was a child I was afraid of many, many things in my family. I think it would have made a huge difference for me if my parents had intentionally sought my 100% trust. If nothing else, we could have cleared up many misunderstandings. I was afraid of things that were completely out of whack with reality. Kids are very creative, tend to over-dramatize, and always imagine the parents as BIGGER and MORE POWERFUL, maybe even SCARY. You might be surprised what they are afraid of once you convince them to share their inner world with you.

So, I recommend the following: Ask your kids on a regular basis what it would take to gain their 100% trust. What would it take for them to feel 100% safe with you? And then be prepared to change if needed. That is a huge gift you can give your kids. Providing a truly safe haven and showing them in real time you have the ability to change.

Project Management with The Core: Rule #1 Be Skeptical of Convention

michele@mccarthy.net — Tue, 07 Sep 2004 12:00:00 GMT

I am starting a new category of essay: Project Management with The Core. Besides family issues, this is the most requested area when clients ask for advice.

The Core supports skepticism. By “skepticism” I mean the questioning of conventional thinking and assumptions. This is very different from cynicism. When I say cynicism I mean the criticism or sabotage of positive endeavor because of a lack of hope and faith. Skepticism is identified by its curiosity and experimentation whereas cynicism is typified by a lack of results and a lack of support for those who do get results.

I was lucky enough to get a manager very early in my working career who was skeptical of conventional program management practices. She supported me in shipping quality products on time by doing what made sense instead of what I was “supposed” to do. When I met Jim, he and I had a similar skepticism for such things and we taught each other what we had discovered in the meantime.

Conventional project management dogma goes something like this:

*Define your goal: time, scope and resources

*Specify your project: the more detail, the better

*Build a schedule for your project: the more detailed the better

*Begin working on your project, adhering to the spec and the schedule

*If you fall behind in some area on the schedule and there’s nothing to be done, include this ‘slip’ in your future schedule and report it to your managers

*Keep updating the spec and the schedule as the project goes

*Ship according to schedule.

In my experience this doesn’t work well at all. You can specify until you believe you’ve thought of everything. You can work hours and hours on a Microsoft Project schedule which details every little dependency in your schedule. You can add months of “buffer” into your Project schedule. And still, you are likely to be late and burned out.

I believe in judging new ideas empirically. So, I can tell you the above doesn’t work and other methods work much better from experience. However, I also have theories about why it doesn’t work.

Team = Product

My first theory about why it doesn’t work is that it is all about bureaucracy and not about people. Creating great products on time is about creating a great team and then having it ship something. If you are spending your energy creating specs and schedules, you won’t have the time or energy to create a great team. A great team is far more important. A great team can invent the product as it goes. It can turn on a dime. It can come up with a BIG idea to bring the schedule in on time when everything seems to be working according to Murphy’s Law. The team members on a great team can cover for each other if someone gets sick or goes on vacation. They can learn new skills in real time because they are passionate about what they are working on and who they are working with. A great team can do everything that a spec and a schedule can’t. And I haven’t once seen a spec or a schedule contribute to the greatness factor of a team.

(For more on Team=Product look at SFYH)

Trust vs. Control

My second theory about why it doesn’t work is that it focuses on control, instead of trust. By “control,” I mean the neurotic type of control wherein we wish that humans were more robot-like and life was more predictable. The interesting thing about desiring this type of control is that it results in less actual control. Desiring control is self-destructive.

One of the new lessons of BootCamp (thank you leaders of Halliburton Energy Services!) is that it is far more effective to replace control with trust. If you put your energy into creating alignment with your team members so that you can build trust, then you can achieve great results. When you can trust that your team members are aligned with you, you don’t have to write every detail down. You don’t have to plan every detail before you implement. You don’t have to have hours-long meetings with too many people in them. You don’t have to “control” what everyone is doing at all times. Because you have alignment and trust.

The Core Project Management

In my experience, the following does work. Every time. If you do this, it will work. You and your team will be heroes.

*Make sure your team is booted (If you believe you are blocked on this step, proceed anyway. You will encounter much more suffering without a boot but you can still ship on time.)

*Get a shared vision for your team’s work (If you believe you can’t do this, proceed and you will probably succeed anyway. You will be missing a level of greatness that comes with shared long term vision, but you can ship something near-term on time.)

*Get a shared vision for what the message of your next version will be

*Pick a date to ship it that aligns with what you and your customers want

*Make a prioritized set of features (aligned with your customers) and begin work on #1, then #2, etc.

*Maintain alignment with your team(I will provide many tools to do this in later essays)

*Practice shipping with interim milestones

*Stop creating with enough time to stabilize your version (usually about 2 months).

*Ship the version on the date you set at the beginning.

(For more on this algorithm read the IDP in SFYH or the BootCamp Manual)

Family and The Core - Mad is OK

michele@mccarthy.net — Thu, 19 Aug 2004 12:00:00 GMT

Dear Friends,

Today what is on my mind is Family and The Core. In particular, I am very inspired by a new idea we discussed a week ago in our family for the first time.

It goes like this.

I am proposing that Jim and I and his 2 youngest kids(9 and 11) get aligned around the idea that:

Mad is OK.

To be more specific I am proposing that we shoot for the ideal I have in mind that when one or more of us is mad, that the others are not scared, simply alerted to the fact that someone is mad which means there is a problem to be solved.

This may seem out of the realm of possibility to some of you.

But I have asked myself recently: Why do I immediately get scared when someone gets mad? It’s because I am afraid he/she is going to act in an irrational way. I think, for me at least, I could get to a point where I’m not scared when certain people are mad because I have established enough trust that I know they will not be irrational when mad.

So, why not in our little family?

It seems reasonable to me. For instance, when I proposed this idea, our youngest daughter said she gets scared when I am mad because she’s afraid I might leave. I’m not going to leave and I explained to her how I know that. I think it’s likely she will feel less fear in the future about that (especially if we adopt this vision for our family).

One objection that could be raised is that I am saying the fear we
feel is not OK. I am OK with the fear, too. However, I think that
there is currently way too much of it flying around. And most of it
is unnecessary. Wouldn’t it be better if there was less of it? Even
a little less of the unnecessary type? I think it’s worth a try.

Another objection I am running into seems to come from a lack of
discernment between being mad and being “fighty.” Mad is just a
feeling. I think being “fighty” is when you exhibit a suite of
behaviors normally associated with anger which are destructive.
These include being mean, sarcastic or bullying, raising the voice,
being defensive, arguing, etc. I know it is possible to be mad
without being fighty. I can do it sometimes and I’ve seen others do it.

I noticed in our last family meeting that the assumption everyone is making is that when one person is mad, the sooner someone checks out, the better. That until the mad person “cools off” we shouldn’t be around each other. This comes from the assumption that if someone is mad, he or she is automatically going to exhibit fighty behaviors.

My vision is that we can, as a family:

1. feel mad without being fighty. We can think and feel at the same time.
2. not feel fear in the face of our family members’ anger because we know they will think and feel at the same time when mad.

Now remember that visions are idealistic, maybe never attainable.
So, it’s probable we would never be perfect at this. But wouldn’t it be so inspiring if we could move in this direction?

The way I have started to change this in our family is to ask each
person what it would take for her/him to not feel scared when I say that I’m mad. As you see above, one of my daughters jumped right in and we made significant progress in clearing up her fears.

Maybe some of you have this dynamic in your family already and we are just catching up.

I am inspired by the possibilities and Jim just told me that he is
too, after thinking about it.

Peace and Health,
michele

p.s. Update. Our youngest has recently taken to calling people she doesn’t think look right “sad,” as a putdown. I told her yesterday that I want her to treat people with compassion instead of being judgmental. Usually, when I tell her I don’t like something she’s doing, she gets scared. So, this time both daughters and I had a discussion after I said this, that there was no reason to be scared. Our oldest daughter said, “I started to get scared and then I remembered, it’s just Michele and I don’t need to be scared.” So, so far the results are good.

Marriage and The Core

michele@mccarthy.net — Sat, 10 Jul 2004 12:00:00 GMT

Jim and I have experimented quite a bit with applying The Core to
everything. A theme I’ve noticed in talking with many of you, is
that you are interested in how to apply the protocols to family and
marriage. I am going to talk about one idea we believe in. I have
several more but this one has a lot of facets so I’ll stick with just
one today.

CheckOut and Marriage

We have found that a key to creating a harmonious marriage is to use the CheckOut protocol *to the letter.* This means that as soon as either one feels that the interaction is not going well, he/she checks out. You can almost always deal with an issue later and get better results. There are very, very few real emergencies. As a friend of ours put it, “the key to a good marriage is to leave each other alone when one of you is in a bad mood.” Well said.

It is important to be strict with each other about the details of
CheckOut.

1. Once someone says “I checkout” he should leave the area
immediately. If you checkout, don’t expect the other person to leave the area because you checked out.
2. When one of you says “I checkout” both of you must ZIP IT! Neither person can say another word at that point. This has been a challenge for me. But it gets easier.
3. Institute a default CheckIn time period. For us, after 2 hours
has passed from any CheckOut, each person is assumed checked back in whether he said it or not.
4. If you want to checkin earlier than the default checkin you can
either say “I’m checked back in” or you can say you are checked in and do a full checkin. We just say “I’m checked in.” You can also acknowledge you are checked in even if the 2 hours has passed. It seems to create connection to declare it.
5. If 2 hours has passed and you are still not feeling integrated,
make sure you extend the checkout. Be sure to make checkouts as long as necessary for you to get what you need to act in a mature way when you check back in.
6. I recommend leaving the house/hotel if you are especially upset
with your partner. There is something about moving that moves your mind too. If you can move away from your space for awhile, it can work wonders on your attitude. Staying at home while very upset seems to make me more likely to stay upset.
7. If there are violations of the protocol deal with them later. For
instance, if you say “I checkout” and your partner says something
back, don’t try to fix it then. Fix it later when you are both calm.
8. To fix violations I recommend meeting when you are both calm and ready to work on the issue, possibly with a good counselor. I
recommend bringing it up like this. “So, I want to make sure we are aligned on using the Checkout protocol. We agree that once someone says ‘I checkout’ then neither person may say anything else. Are we aligned on that?” Something along those lines works well.
9. A really important part of Checkout is that both partners “get”
that it is always a good thing. Checkout is a smart thing. It is
not OK to shame or punish the other person for checking out.
10. If you are thinking that it is not OK for your partner to
CheckOut, then you need to ask for help. Because that’s about your feelings. Your partner is being wise. Your feelings suggest
something going on with you, not your partner.
11. If it seems like you are in a continual state of CheckOut with
your partner (lots of Checkouts when you are together), then you need a good marriage counselor. You have a boot problem. To make improvements in your collaboration, you’ve got to get to a point where you can both stay calm and mature with each other at the same time for a significant amount of time.
12. Remember that counseling is a luxury, not an admission of
failure. We are so lucky to live in a time and place where there are
people whose only job is to help us make our emotional lives better. I go to a counselor even when things are going great.

Well, this will probably end up in a book about Marriage and The Core someday. This is my first draft. I hope it is helpful. I’ll talk
about more ideas later.

Truly,
Michele