Chicago’s Rollout–Change a Habit (3)

In a project, there are five phases:  initiating, planning, executing, monitoring and controlling, and closing.

With the project of changing a habit, let’s take the first phase of initiating.   This is where you come up with a definition of your project’s goal.   In this case, it’s where you want to change a habit.   So let’s call this step 1.

1.  Choose a habit you want to change

Now let’s talk about planning the project.   You’re going to want to figure out how long you are going to give yourself to complete the project.

2.  Choose a timeframe for the project

Many experts talk about a new habit being established or an old one being changed in about two weeks.

In order to change the habit, we need to analyze the habit loop and figure out what the CUE or TRIGGER, ROUTINE, and REWARD are.

3.  Become aware of the CUE for the habit.

We’ll assume you already know what the ROUTINE is you are trying to break.   But you also need to figure out the REWARD.

4.  Figure out what the REWARD is.

Once you know the reward, you can then figure out how to insert a different ROUTINE after the CUE so that you get a similar REWARD.

5.  Figure out what the replacement ROUTINE will be.

Once you have figured out what the replacement ROUTINE should be, you are now ready to execute the project.

6.  Start the project:  use CUE awareness to become more aware of the CUE, and when it occurs, use the replacement ROUTINE.

You should start recording your progress, so you can review it at the end of the first week, and then at the end of the project in two weeks.

7.  Mark on an index card a check mark every time you catch yourself doing the CUE for the ROUTINE.

8.  Mark on an index card a hash mark (#) every time you successfully carry out the replacement ROUTINE.

9.  Review your progress after one week.

10.  Review your progress at the end of the second week when your project stops.

The last step is the closing progress, because you decided how long the project would last back in Step #2.

So this shows you how to write the steps of a project in a way that divides them into the five phases mentioned above:

Initiating–step #1

Planning–steps #2-#5

Executing–steps #6-#8

Monitoring and controlling–steps #7-#9

Closing–step #10.

Now that is the outline of a project.   Let’s go to the next post for more details about how to practically get this done in your daily life, starting with CUE awareness.



Chicago’s Rollout–Change a Habit (2)

In the last post, I talked about the elements of a habit loop, the CUE or TRIGGER, the ROUTINE, and the REWARD.

In the case I discussed in the last post, that of biting one’s nails, the ROUTINE is obvious, that is, it’s when you bite your nails.   The CUE or TRIGGER is when you are bored or anxious and therefore tense.   What does the ROUTINE of biting your nails do for you?   It creates an irritation or momentary pain which reduces tension.

So how do we go about changing this habit loop so we don’t bite our nails?   What scientists who have studied this habit recommend is that, every time you feel the CUE or TRIGGER happening, you should replace the ROUTINE of biting your nails with the following new routine.   You should take your nails and scratch them against the inside of your wrist.   Not hard enough to draw blood, or anything like that, but vigorously so that you can feel the nails rubbing against the sensitive skin on the inside of your wrist.

What does that do?   It is an irritation that, like the irritation of biting your nails, reduces tension.   This amounts to the same reward in the brain as before, but now you’re doing something that is not destructive.

This is an example of how to change a habit–you don’t change the cue or the reward, but you try to get a similar reward with a different routine.   And that’s all there is to it!   It’s simple–but it’s not easy.    Experts differ on how long it takes to change a habit, but many say it is about two to three weeks.    So let’s do a project and change a habit.

How do you go about doing this?   It’s a step-by-step process, which I’ll go into in the next post.


Chicago’s Rollout–Change a Habit (1)

On Chicago’s Rollout radio program on Friday, February 21st from 6:30 to 7:30 PM CST, I covered what a project is (see last post).

I wanted you to explore for yourself what a project is by doing a project for yourself, namely, to change a negative habit you have or to establish a positive habit that you would like to have.

However, before you start on your project to change a habit, you should understand something about how they work.   If I ask you to identify a bad habit, that shouldn’t take you too long to do.   In my case, I noticed that I was biting my nails during the third broadcast a few weeks ago, and I wanted to try to stop doing that.

So I got the book The Power of Habit: Why We Do What We Do in Life and Business by Charles Duhigg.   In the book, he shows you how to understand your habits by analyzing the habit loop (I’ll describe this below).   I have been working on stopping this bad habit for the past few weeks now, and then I realized it would make a great example project for those of you who are listening to the program.

Before you set up your project, let’s understand HOW to change a habit.   To do this, you need to understand the habit loop, which consists of three steps:


In the case of biting your nails, researchers studying the brain have shown that the CUE or TRIGGER is either boredom or nervousness, both of which create tension in the brain.

The ROUTINE of biting one’s nails creates a sharp sensation of irritation and even momentary pain.   This is what causes the REWARD of a lessening of tension, because when you have that irritation or momentary pain from biting your nails, it relieves that tension which the brain wants to get rid of.    By tying these three elements together, your brain has now created a habit loop.

So knowing this, how can we use this information to change the habit?   That will be the subject of the next post!


Chicago’s Rollout–What is a Project?

Welcome to those who heard the radio broadcast on Friday night (6:30-7:30 CST, February 21st) of Chicago’s Rollout program on!  This was our first show on the subject of project management which was titled “The Projects.”   What I’m going to do in the next few posts before our next show is introduce the definition of a project and then give you a project to work on called “Changing a Habit.”  Feel free to leave a comment or a question below.


DEFINITION OF A PROJECT–ordinary and technical definitions

When we talk about a project, the ordinary definition tells us that a project is a “large or major planned undertaking.”   So it’s a lot of work that is somehow organized to get done in a systematic way.

What is the technical definition of a project according to the Project Management Body of Knowledge?   It is a temporary endeavor undertaken to produce a unique product, service or result.

Let’s look at the technical definition more closely.


This means that it has a start and a stop.   Each project has five phases, the first of which is the “start” of a project called the initiating phase.   The fifth or last phase is the “close” of a project and it is called the closing phase.

It is in contrast to the operations of a business, for example, which are example of continuous activities that keep on going indefinitely as long as the business continues to exist.   The regular business operations are covered by Bert Howard in his segment on “Business” during the first week of every month.


If you have an idea for some new product, you can create a project to design, manufacture, and distribute that product.    But the Project Management Institute realizes that there can also be a project which improves upon an existing produce, service or result.   The project we will do on changing a habit is exactly this other type of project, because what you will be improving upon is yourself, by getting rid of a bad habit or starting a good one.


As we see above, a project can be started to create a new product.   But you can also start a project with the aim of creating a new service.  Let’s say that you want to open a transportation service to help those in your neighborhood who may not have access to public transportation to get groceries, go to doctor’s appointments, etc.   Setting up a company to provide that service would also be an example of a project.

Finally, a project can produce a result, such as the creation in a church of a directory of members so that people can get a hold of their fellow church members outside of church.

So the above covers what a project is about.   The next posts will cover Creating a Habit and I will put these posts up between now (starting Sunday) and the time of next week’s program on Friday, February 28th.    Next week’s program will be led by Bert Howard and will cover art, architecture and design.   We’ll see you all on the next … Rollout!

(NOTE:  For those who are regular readers of this blog, the “Chicago’s Rollout” blog posts are geared towards those who have no background in project management.   We are assuming that the listeners want to understand basic concepts of project management in the hopes that they can use the material to improve their everyday lives on a practical level.   Of course, it is always our hope it may spark an interest in studying the subject further.)

Welcome to Chicago’s Rollout!

Welcome to all those who are coming to read more about what was discussed in the Chicago-based Rollout radio program!

My name is Jerome Rowley and I am the co-host of the program together with my colleague and business partner, Bert Howard.

The Chicago’s Rollout radio program is sponsored by TruthRadioChicago, which you can access at “”.   Our show airs on Friday evening from 6:30-7:30 PM.  For those of you with Android phones, you can download the “TruthRadioChicago” app and listen to us that way.   (No word yet on the availability of the app on the App Store for those with iPhones.)

The mission of the program is initially to reach out to the African-American community in Chicago and present information to you that will help empower you through education, in order to be enlightened and energized for the future and become engaged in the world.    The four subjects areas we will be covering are:

  • business
  • logistics
  • project management
  • art/design (plus architecture)

Project management is my specialty area, and the other three areas are the specialty areas of my co-host Bert Howard.

If you want to write a comment, or ask a question, leave a comment towards the bottom of the page this blog post is on, or contact me on my Twitter account, which is @4squareviews.    This is a moderated blog, so I have to approve comments before they are posted.   I will try to respond to all questions as time permits.

I will be posting in the next week articles that have to do with the material we covered on our program of Friday, February 21st.   Our program tonight will cover the definition of a project, and an example of a project you can do to help change your life, mainly to change a habit!

As the saying says, “change nothing, and nothing changes”!

Agile Bodies and Corporate Antibodies

This is a review of section 6.1 Organizational Change Management in the Agile Practice Guide.   The particular topic being covered on pp. 73-74 is how organizations can either accelerate or impede the evolution of agile practices.   I used the phrase “corporate antibodies” because I heard it during a meeting of the PMI Chicagoland’s Executive Council during my tenure as the Director.  The discussion was how to create and foster an agile culture on projects.   One of the executives present said that creating an agile culture wasn’t the problem.   He said that the real problem was AFTER the project was completed.   He said that the enthusiasm and ideas from the members of the project team would start flowing into the organization, but would be stopped by what he called the “corporate antibodies”, meaning the traditional views of project management that were held by upper management.    This is just an example of how an organization can impede the evolution of agile practices.

Let’s go over the positive and negative ways an organization’s leadership can impact the spread of agile culture.


Here’s the positive ways an organization’s leadership can influence the spread of agile culture:

  • Visible and active executive sponsorship of agile projects (their presence at kickoff meetings is an essential part of this)
  • Using communication and coaching to facilitate the change in corporate culture
  • Progressively pacing the adoption of agile practices on a project-by-project basis
  • Incremental introduction of agile practices to the team through agile coaches
  • Leading by example by having management use agile techniques and practices whenever possible


On the other hand, management can impede the spread of agile culture in the following ways:

  • Creation and maintenance of departmental silos–this creates dependencies (hand-offs between departments) that in turn prevent accelerated delivery
  • Procurement strategies based on short-term pricing strategies rather than long-term competencies
  • Leaders are rewarded for temporary efficiencies rather than the end-to-end flow of project delivery
  • Employees are not given incentives to diversify, but rather to remain specialized contributors to a project
  • Decentralized portfolios pull employees into working simultaneously on many projects at once rather than having them focused on one project at a time.

Given these two choices, management has to decide which would rather have:  agile bodies adding value to an organization, or corporate antibodies that try to prevent it…

1,000 Days of Duolingo

This morning I achieved a milestone by reaching the mark of having used the language-learning app called Duolingo for 1,000 days in a row.   I have tried to create a long-running streak before, but I was always so busy I would forget to use it on a given day and, well, there went my streak!   THIS time I was determined to make it a rock-solid habit, so I made sure that I used the app and got 50 experience points (which the app considers to be the INSANE level of a daily goal) before I even got out of bed.   This is what has made the achievement possible.

One of the reasons why I like Duolingo is because it is already changing and always improving.    They keep adding more languages, and sometime last year, they added an additional challenge by adding 5 levels of difficulty to each language.   I had finished the all the skills in the “skill tree” for several languages (Spanish, French, German, Japanese and Chinese), and now I am simultaneously going back and working on each language to get each to level 5 and learning some new languages from the beginner level (Portuguese, Italian, Russian, Hindi, Korean).

Another set of features they have added are new modes of learning, so you can read stories, or listen to a series of podcasts in the language you are studying.   They have rolled these new features out for Spanish, and they are seeing if they are popular enough to create the other languages.

The basic feature of Duolingo, however, are the “skill trees” that focus on one skill at a time (such as a category of vocabulary or a grammar point), starting from the simplest (present tense) and going to the most complex (the conditional and subjunctive tenses).  They have added skills to the most popular languages (such as Spanish and French) and will probably continue doing this with the other languages as well.

In short, it never gets boring because if you complete a skill, a level, or an entire language, there will new content to learn the next week.   It’s why it has been such a pleasure to go on this journey of 1,000 days.

Why am I so into this language-learning app?   I’ve been a lifelong fan of learning foreign languages and about cultures of other countries since I was the age of 6.   My uncle came to visit and he had been living in Honduras for several years as an engineer.   He was divorced, but remarried a woman from Honduras and he was bringing her to meet my parents (he was my mom’s younger brother).    I was amazed at his ability to speak one moment in a way that I could understand, but then he would suddenly turn to his wife and speak some sort of gibberish that I couldn’t.    I started asking questions and he explained to me that he was speaking a different language.   I had heard of other languages, but never saw a person who could switch effortlessly between them.  I vowed that some day, I would like to be to do that too.

And so I did.   I studied Spanish in high school, French and German in college, and Japanese and Chinese in graduate school.   My problem is keeping them from fading in my mind from lack of practice by trying to practice them all at once.   It seemed an impossible task to organize given my busy life until Duolingo came along and it enabled me to do this every day, and to enjoy myself in the process!

So if you sign on to the Duolingo app, add me as a friend.   My real name is Jerome Rowley, but my username on Duolingo is Luojieli, because that is my name in Chinese!

Drivers of Change in an Agile Environment

I am going through the material in Chapter 6 of the Agile Practice Guide, which focuses on organizational support of an agile project.

Here are the changes particularly associated with agile projects, and why they have to be considered in any change management approach.

  • Accelerated delivery–Agile is an approach that focuses on delivering project outputs early and often to the customer (the “incremental” part of agile) and giving feedback from the customer back to the team on a regular basis (the “iterative” part of agile).   On the organizational side, it is important to discover and deliver the features of the product to the customer.   But as the pace of delivery increases, it is important on the customer’s side to be able to accept the delivery and validate that it aligns with the project objectives, or point out where it doesn’t align in as clear a manner as possible.
  • Learning curve–when an organization is just beginning to use agile approaches, there is a high degree of change when learning to accept the culture of agile.  Agile will require more frequent hand-offs between teams, departments, and even vendors.   Change management techniques can help address the hurdles of transitioning to agile approaches.

So it is not just a learning curve to learn the culture of agile, but an acceleration of already existing communications.

The problem in many organizations is that agile is seen as something that replaces traditional project management.   A better way to see this is that it transcends and includes a lot of the traditional structures in the organization, and can end up transforming them.   An example is with the “lessons learned” process, which in traditional project management was typically done at the end of a project (at least according to the 5th Edition of the PMBOK Guide).   When agile came along, this lessons learned process was still done, but not at the end of the project, but rather at the end of each iteration.   Any lessons learned were applied directly to the project at hand, and not at some hypothetical project in the future that may or may not take place.   This accelerated improvement not only made the project better, but those “best practices” that developed during the project could be used by the organization as a whole or even by other project teams.

This is an example of how agile did not replace a structure from traditional project management, but instead it transcended and included it (by having it incorporated into each iteration).   It proved so useful that in the 6th Edition of the PMBOK Guide, it is no longer a part of the “Close Project or Phase” process in the Closing process group, but is a separate process that it done during the Executing process group, as process 4.4 Manage Project Knowledge.

So with this more positive way to thinking about agile approaches, what are some of the characteristics of organizations that make supporting agile principles easier?   And conversely, what are some of the characteristics that may be roadblocks to achieving agile principles?   This will be the subject of the next post.

Change Management in an Agile Environment–A Moment of Zen

The subject of the 6th chapter of the Agile Practice Guide is the ways in which the organization at large can support an agile project.   The previous chapter covered the subject of implementing an agile project by creating an agile environment within the team.    The theme of this chapter comes from the statement on p. 71, the first page of the 6th chapter:  “Project agility is more effective and sustained as the organization adjusts to support it.”

The first topic in this chapter is change management in an agile environment.    In my opinion, the biggest difference between change management in an agile environment and a traditional project management environment is a psychological one:   the goal is that change should be seen as a positive good rather than as a necessary evil.

A graphic way to understand this comes from a book I am reading now called The Zen Leader by Ginny Whitelaw.   She talks about transforming your consciousness so that you can go from passively coping with problems or changes to actively using those same issues to transform your team and your organization.

A clue to how to do this transformation comes from her explanation of what you have probably seen demonstrated by a karate instructor:   focusing your energy on breaking a board.   She explains that the trick is that the person who wants to break the board does not focus on the board.   If you are trying to break the board, you focus your physical and mental energy on a point behind the board.   You are trying to reach that point, and the board is just something you go through in order to get there.   She says that seeing a problem and focusing on it is a way of coping with the situation.

If there is a problem that the project team encounters, the ways of passively coping with the situation are as follows, from the worst to the, well, least bad:

  • Denial (what problem?)
  • Anger/Rage (hey, what gives–this messes up our comfortable status quo!)
  • Resistance (do we HAVE to do this? Is there any way we can mitigate the change (i.e., sabotage it)?
  • Rationalization (we don’t want to do this, but we’re being forced to by outside forces outside of our control)
  • Tolerance (it’s a necessary evil, but it has to be done if we want to go forward)

If you focus your team not on the problem itself, but on what the solution could possibly mean for the project, then you are flipping your mind from merely coping with the problem to transforming it.

Here are the stages of transforming as opposed to coping with a problem (from the good to the best):

  • Acceptance (well, we don’t have a choice about the problem, but we do have a choice about how we react to it)
  • Joy (if we were to make the change, it would make our customers happier, and benefit our organization)
  • Enthusiasm (let’s all roll up our sleeves and think of how to get there!)

Saying this is one thing, doing it is, of course, another.    One mental exercise she has to help you shift your mind into positively accepting the above three stages is the following.

  • Relax–raise your shoulders up to your ears, the way people do when they are tense.   Drop that tension, and exhale.   Sense that your awareness is going out of your head, and into the center of your body.    Start breathing from the belly or lower abdomen–it will continue your relaxation.
  • Enter–Picture a circle, like the eye of a hurricane, that you can enter.   Although all around you are the swirling patterns of reaction to the problem (the “coping” described above), you now see that inside the circle you see the situation as a puzzle or a game.   This will allow you to enter a flow state where you start to engage your creativity.
  • Add value–From the creativity within that you have engaged in the previous step, project this energy outwards to the other members of your team and lead them into your circle.   The energy will lead your team to help you add value by reaching towards a solution.

This book has been tremendously helpful to me in dealing with problems or changes on a project, and I thought it was important to start the section of Chapter 6 dealing with change management to show how important a psychological shift is when going from traditional project management to agile.

In the next post, I will discuss the particular changes associated with agile approaches.



Agile Measurements: Lead Time, Cycle Time, Response Time

This is a continuation of the discussion of section 5.4 Measurements in Agile Projects of the Agile Practice Guide.

Measurement of the progress in doing a project is different between traditional and agile projects.   Traditional projects used Earned Value Management, which takes the unit of measurement to be the number of dollars (or whatever currency the organization is using) budgeted for the completion of a work package.

There are basic building blocks to the measurements in Earned Value Management.

  • Planned value (PV)–this is the authorized budget assigned to the work that is scheduled to be done.   (The key word there is “scheduled”.)
  • Earned value (EV)–this is the measure of work actually performed.   (The key words there are “actually performed”–it is a a measure of how much scope was accomplished.)  This is expressed in terms of the budget authorized for that work.
  • Actual cost (AC)–this is the measure of the actual cost for work actually performed.  (The key word is obviously “cost”.)

To get the Cost Performance Index, you take AC/EV, and to get the Schedule Performance Index, you take EV/PV.

In agile, the unit of measurement is a story point, which is an estimation of how “big” the user story (i.e., a feature of the product being created) is.   It is a relative estimation, so the size of the smallest feature may be designated arbitrarily as 1, and the other features given a number of story points in comparison.

When I was initially studying about agile, I thought that Earned Value Management wouldn’t be used, but an analogy can be used in an agile environment.   For example, an analogy of the Schedule Performance Index can be used.  SPI in a traditional project environment would equal

SPI = EV/PV = (value of work actually performed)/ (value of work planned)

Since PV and EV are both in units of dollars, you get a simple ratio as a result.   An SPI of 0.80 tells you that your team only got 80% of the work done.   Analogously in an agile environment, if you take SPI now to mean

SPI = (number of story points actually completed)/(number of story points planned)

then you can compute the SPI for a given iteration.   If you planned on completing 20 points in an iteration, and the team actually only completed 15, then the SPI is 15/20 or 0.75.

However, one of the main differences between EVM in a traditional vs. agile environment is the following.   In traditional EVM, earned value or EV refers to the work completed by the team.   However, EV in an agile environment refers to work that is not only completed by the team, but shown to the customer and validated that it conforms to their understanding of the requirements.   Because if it does not conform, then the item or feature has to be reworked.   It is not just work that is complete, but work that is also correct, that counts in agile EVM.

Now there are two ways of setting up iterations in agile.   One is take an arbitrary amount of time (usually referred to as a timebox) and then you take a measure of your progress every two weeks or however long the iteration is.   The team following this approach is referred to as an iteration-based agile team.

There is another way of marking progress, and that is having the iteration not be specific length, but the length of time is takes to do the next feature in the product feature backlog.   The team following this approach is referred to as a flow-based agile team.

The measurements used with flow-based agile teams are listed below in relationship to a Kanban board.  The “ready” column on a Kanban board is the list of features from the product feature backlog that are ready to be worked on, usually the left-most column.  When the item is ready to be worked on, it is removed from the “ready” column and put in the development column to its right.

  • response time (the time that an item waits in the “ready” column until the work starts)
  • cycle time (the time that it takes to process an item once the work starts)
  • lead time (the total amount of time it takes to deliver an item, from the time it is added to the board in the “ready” column to the moment it is completed)

As you can see from the above definitions, the lead time is equal to the response time plus the cycle time.   The cycle time measures the work in progress.

According to the Agile Practice Guide, the cycle time can be used by a flow-based agile team in order to see bottlenecks or delays, whether they are inside the team or external (based on interactions with the customer or sponsor, or perhaps caused by delay of delivery of resources from a vendor).  The next post will talk about a cumulative flow diagram, a way of representing the measurements listed above, which can give clues as to the source of those delays.