Author Archives: Michael B Bender, MBA, PMP, CSM

Papyrus, White Boards, Glibness, and Cerebral Knowledge

Category : Project Management

Glibness (n): fluent but insincere or shallow.

I once consulted to a high-tech engineering company outside of Pittsburgh. The engineers had attended one of my project management seminars a short time prior, and asked that I come in and do a bit of coaching.

One of the best students in the class asked for some help with his project. He was about half-way through the project and looking for some guidance to help him finish. We met, exchanged pleasantries, and got to work. I went through my usual checklist and inevitably came to the precedence diagram (a diagram showing the sequence and flow of the project work). “Of course I have one”, he responded (as I had stressed this topic in the class).

“Excellent, let’s pull it out so I can see it”, I replied.

“Well… it’s in my head”, he responded.

It took a half-second for me to recover (I didn’t expect that response), put a smile back on my face, cleaned off his white-board and said, “Okay, let’s go through it.”

The next few minutes went exactly as I expected. He started confidently, telling me what activities were currently active and what followed them. It didn’t take long before the confusion started. “Oh, wait, I forgot about (some task)”. “Oh, yes, then there’s (some other task)”. This went on for a short while.

Tasks were missing in his head. He had thought about them at one time, but his mind relegated them to the background. He hadn’t thought through the sequence (we changed many sequences during the exercise, and had to add a few new tasks). But after we were done on the white board, we had a solid plan to finish his project. The entire exercise only took about 20 minutes.

We’ve become a cerebral society. If we need information, we just GTS (Google the S[tuff]) and move on. We tend not to study it, we don’t analyze it, we frequently don’t even challenge it (after all, it must be true… it’s on the internet). We get fast answers to quick questions and move on.

It’s a form of glibness, a shallow understanding of the topic. He is a bright engineer, caring, hard-working, and wants to do things right. He just kept everything in his head, never put it on paper or a white board, or even in electronic format. He never spent the time to really look at the sequence, challenge assumptions, and get it right.

The problem is the mind forgets, it automatically re-prioritizes what’s in short-term memory. Things go missing, they go to the background, and of course, the mind doesn’t bother telling us when it does this, it just does it.

Examples of this are so numerous I dare not mention them all. One of the techniques Kimi and I started doing some time ago in our speeches is asking senior managers if they ever laid out all their projects in front of them to see how resources were allocated. Their usual response… deer in headlights! That tells me that if they actually did that, they’d realize the difficulties they were placing on their staff.

I still love paper. I frequently sketch things out on white-boards, go over it many times (and usually with a second pair of eyes); then, once I truly understand it, it will end up in electronic format somewhere so I can pull it up any time. I write down my assumptions, decisions, and rationales. I can’t tell you how much time this saves me.

While I believe mankind is getting smarter, we still can’t just run things from our heads. We can’t run projects from our heads, we can’t manage strategic plans, business processes, or research cerebrally.

Try it. Spend the time and effort, lay it out, see it in the physical universe, and go over it several times. Peer review it… have another pair of eyes look at it. It’s amazing what you’ll discover and the mistakes you’ll avoid and the time you’ll save!

… not that I’m opinionated on this!


Michael B Bender

How Much Time Does Your Team Actually Spend Working?

Category : Project Management

How much time does your team actually work during the day?

In live seminars, I run a quick survey of team productivity. I call it the “Other Stuff” list. It’s a list of all activities individuals do during the day that is not project work. I then ask students how many hours they spend on a typical week doing each of those activities. After 20 years of running this exercise, I’m still amazed at the results.

I encourage you to run this exercise with your team or colleagues. Take a white board, flip chart, or simply a piece of paper. Ask your team to list all the activities they do during the day for which they get paid. Then, ask them how much time they spend in a typical week doing each of these activities. For daily tasks, ask how much time they spend during the day and multiply by 5. For yearly tasks (vacations, holidays, etc.), divide by 50 (or 52 if you want to be more precise). Remember, it should only include activities for which they are paid. For example, if you’re paid for lunch, include it, otherwise, don’t. Here’s a sample list:

  • E-Mail, Voice-Mail
  • Meetings (non-project meetings)
  • Biological needs (coffee breaks, etc.)
  • Social needs (chit-chat)
  • Training
  • Your “real” job
  • Firefighting/Emergencies
  • Equipment problems (computer problems)
  • Mentoring, helping out your colleagues
  • Vacation, holiday, sick
  • Travel

If you’d like to see how I do it, play my short video on Estimating Basics, Micro-Lesson 1. I think the results will surprise you as well.

May all your projects be successful!


Managing Task Interdependencies – Building a Culture of Performance

Managing Task Interdependencies

The Challenge

Managing task interdependencies is one of the most challenging aspects of project management. A recent study indicated that 70% - 80% of project changes can be attributed to internal (and controllable) issues, not client issues. Consider the following diagram:

Figure 1: Project Precedence Diagram

Most project managers will recognize this as a precedence diagram or PERT chart. Each node represents an activity within the project. In essence, it’s a work-flow diagram. Once the project starts, tasks A, B, and C can start and each can run in parallel. Task E requires the outputs of A and B. For example, task A might be surveying a plot of land to create a plat. Task B might be laying out the overall structure of a house. Task E might be locating the house on the lot. Errors or omissions in task A or B, therefore create problems in task E. In order for the team conducting task E to complete their work, they must re-engage team A and team B to resolve the issue.

Now, consider that any error or omission isn’t discovered until task Q. Issue resolution now requires engaging many of the previous teams, creating a large number of project changes.

The effects of these issues can be easily identified in a variety of ways:

  • Large number of changes found toward end of a project
  • Team members spend more time addressing issues, getting questions answered, or gathering information than they do performing the work
  • Frequent “emergencies” to address issues to get a product out on time
  • Project delays increase as the project proceeds

In its simplest form, ask yourself how many times you go to your favorite home improvement store to finish a home project (upgrade a closet, finish a basement, remodel a room, etc.) The common element in all these effects boils down to managing task interdependencies.

The Lexicon

The discipline of project management, like all disciplines, consists of a set of esoteric terms which may not be obvious to all readers. To address both formal project managers and the general readership, we define the following terms:

Task or Activity:  A specific action that creates a deliverable, result, or work package. Formal project management defines a work package[1] as a well-defined component of a deliverable. Activities (or tasks) represent the steps needed to create the work package.

Predecessor:       Task or activity that precedes (comes before) another activity. The result of the predecessor becomes the input to the successor.

Successor:           Task which follows another activity.

Deliverable:         The artifact that is transferred to the successor activity. Sometimes called the result.

Why are Task Interdependencies so Challenging?

Projects are likely the least understood of the work endeavors performed in organizations in both the fields of practical management and academia. Unlike other organizational endeavors, projects form a complex network of activities as depicted above.

If you have an MBA, you may have studied the subject of Task Complexity. While several models of task complexity have been offered over the last few decades, most fail to address the characteristics of complex networks (e.g. projects) (Haerem, Pentland, & Miller, 2015). Charles Perrow, for example, divided activities into four categories based on task variability and task analyzability (Jones, 2013). James D. Thompson (Jones, 2013) developed the theory of Task Interdependence. This theory categorizes organizational work based on the interdependencies of tasks needed to convert inputs to outputs. One such category is called Long-Linked Technology which is based on sequential interdependence.  Thompson’s model suggests linear dependencies such as those found in production lines or business processes. In sequential interdependence, the output of one task becomes the input to the next task. The results of the first task, therefore, affect the performance of the second task (a domino effect).

While Thompson (Jones, 2013) and others recognize the domino effect of task interdependency; projects, by their nature exhibit a greater degree of complexity than seen in sequential interdependence. Haerem, Pentland, and Miller (2015) recognized the consideration of task antecedents regarding task complexity, expanding this view.

Simply put: sequential interdependence suggests that each task has a single predecessor and a single successor. However in projects, tasks have multiple predecessors and successors. In sequential interdependence, problems grow linearly as they move through the endeavor. In complex interdependence (e.g. projects), problems grow exponentially.

Managing Task Interdependence

Managing task interdependence is simple in form, however it requires a high degree of rigor. First, we consider the form (using a step-by-step analysis), second, we consider the rigor.

Managing Task Interdependence – the Steps

Step 1: Start with a complete list of activities

Most project managers are familiar with the Work Breakdown Structure (WBS). The project manager works with the team to create a complete list of activities for the project. Creating a WBS involves decomposing high-level deliverables into specific steps (or activities) needed to create each deliverable.

It is beyond the scope of this paper to present the details of either the activity of creating a WBS or its characteristics. For the sake of this presentation, we simply assume that the WBS creates a COMPLETE list of all activities needed to complete the project.

Step 2: Identify the Predecessors and Successors of each Activity

The project manager works with the team to determine what each activity needs to start. Using our previous example, we ascertain that determining where a house will be located on a plot of land will require the outside dimensions of the house and the plat of the land. Certainly, it also might require more inputs, such as the building requirements regarding the buffers needed between the building and edges of the lot. The project manager employs the expertise of his/her Subject Matter Experts (SMEs) to establish all the needed predecessors (inputs).

Step 3: Determine the Complete set of Requirements of Each Activity

Once the predecessors and successors have been established, the team SMEs must clearly define each activity. This includes determining the specific requirements that each predecessor needs to ensure the following-task performers have all the correct information they need. This step, perhaps is the most challenging within the framework. The activity requirements must meet two conditions:

  • Succeeding tasks need to have all the information and artifacts needed to complete their tasks
  • Activity requirements must support the ultimate customer’s requirements

Several tools exist to aid in development. One such tool is the Goals Breakdown Structure or GBS (see The Goals Breakdown Structure later in this document). Another common tool is called Requirements Traceability.

Step 4: Execute the Activity

Once the activity is well defined and contains all the requirements needed to satisfy both the customer and succeeding tasks, the project manager assigns a skilled team member (or members) to perform the activity.

During this step changes may be discovered. Requirements may be inaccurate or incomplete; or technical, design, or scheduling issues may arise. As they do, these need to be immediately communicated to both the project manager and succeeding task performers.

This is a crucial part of execution. This resolves issues quickly and at minimal cost ensuring a smooth project flow.

Step5: Ensure Rigorous Quality

Ensuring rigorous quality classically involves two sub-steps: unit testing and peer reviews. As each task completes, the task performer, with the aid of others, ensures that each task requirement has been met. The task performer first runs unit tests to ensure all requirements have been met. While necessary, unit testing is insufficient. Have you ever tried to proofread your own documents? Generally, you’ll manifest the same mistakes testing the results as you made in creating the results.

The next sub-step is a peer review. Peer reviews bring extra pairs of eyes to the results to ensure compliance. Peer reviews not only ensure all requirements have been met, they also allow the team to exchange best practices.

Step 6: Transfer the Results and Report Discrepancies or Changes

Once the peer review is complete, the task performer transfers any changes along with the task results to all the succeeding tasks, and completes their administration (recording actual times and costs, and handling any other administrative activities).

This completes the task.

The Goals Breakdown Structure

Breakdown structures simply are hierarchical decompositions of larger items into smaller items. Most project managers are familiar with the Work Breakdown Structure (WBS). With the WBS, project managers with help from their team members, break down higher level activities (or deliverables) into smaller activities (or components of deliverables).

Goals exhibit the same hierarchical characteristics (Juran & Gryna, 1988). For example, to build a table, one must first determine the overall characteristics (requirements) for the table (size, height, finish, weight requirements, etc.) Then, one can determine the characteristics of each component of the table (size and shape of the top, legs, etc.). The lower-level characteristics must align to ensure the completed table meets the higher-level characteristics. For example, the length of the legs plus the thickness of the table top must add up to the overall height of the table. The legs must be finished the same way the top is finished, etc.

In projects, there are at least four separate layers of hierarchy. These are:

  1. Overall goal of the project
  2. Organizational objectives
  3. Product requirements
  4. Component specifications or requirements

Larger, more complex projects may exhibit more layers, but we’ve found in our experience that these four layers do nicely for most projects. Consider figure 2.

Figure 2: Hierarchy of a Goals Breakdown Structure

The top layer is the primary mission or goal statement for the project (frequently called the Project Statement). Example: Create a beautiful dining room table to entertain 8 – 12 guests in a formal atmosphere.

The next layer is the business objectives. These include (typically) 5-7 measurable (if possible) goals the business desires the project to achieve. These are typically represented in the organization’s strategic plan.

A partial set of business objectives for the table project may include:

  • Table shall be a classical “old world” style
  • Table shall allow for a minimum seating of 8 people and a maximum seating of 12 people
  • Table shall cost no more than $4000
  • Table shall be ready for service by 11/17/18
  • Table shall resist staining from hot (180o) or cold (10o) plates placed directly on the top

The third layer is the project’s requirements. These include a (usually) large number of both product and project requirements (or characteristics) needed to meet the business objectives. These are created by the customer and the performing organization’s business analyst. A partial list of requirements may include:

  • Table shall be made of mahogany
  • Table shall be prepared with no less than 4 coats of polyurethane
  • Table shall be 12’ long x 3’ deep x 2.5’ high ± 1/8 inch
  • Table shall be able to support 400 lbs.
  • Table shall provide for an extendable leaf of 3’ x 3’

The last layer of the GBS contains the specifications or requirements of the individual tasks within the project. These are developed by the technical staff or SMEs. Specifications for the legs must take appropriate higher-level requirements into account. Assuming the thickness of the table top is set at ¾ of an inch, a partial list of component (or activity) specifications for the legs may include:

  • Legs shall be 2’ 11 ¼ inch in height ± 1/16 inch
  • Legs shall be mahogany
  • Legs shall be prepared with no less than 4 coats of polyurethane

As one can see, certain changes in the manufacture of the top may affect the legs. Using a simple example: if the team building the top discovers that they can’t use a 3/4 inch top, the height of the legs must be adjusted accordingly. If this issue is not communicated, the result will be a table of the wrong height, causing rework and potential “emergencies” at the end of the project.

The Issue of Rigor and Culture

Initially, the level of rigor needed for successfully managing a project may seem onerous. However, our research suggests that this issue is more about culture. Several pockets of cultures exist where this level of rigor is the norm, it’s just the way things are done. It’s habit, it’s standard, and it’s in the threads that bind the organization.

In such organizations, goals breakdowns are part of every design. Aligning lower-level requirements to higher-level requirements are incorporated within each project (in US government contracts, the process is called Requirements Traceability). Peer reviews are commonplace. Changes are immediately communicated to management and adjacent teams.

Such organizations complete projects faster and with higher-quality by eliminating the confusion, frequent interruptions, and problems associated with many projects.

Focusing on cultural improvements that align with productivity can substantially improve organizational productivity. These cultural characteristics (called Key Success Parameters, or KSPs) become the basis of designing a high-performance organization. In such organizations, managing task interdependency is not onerous, it is a norm, it is habit. A brief description of each KSP follows:

  • KSP 1: Clear Definition

Staff and management habitually clearly define the requirements of specifications of each activity within the project. They ensure requirements trace up to meet customer’s requirements and ensure all succeeding task performers have all the information they need to complete their tasks.

  • KSP 2: Ownership

The project manager assigns an individual who is responsible and accountable for the successful completion of each task, for communicating changes in schedule, cost, or requirements, and ensures all requirements have been met.

  • KSP 3: Customer Focused Deliverables

Team members ensure each activity’s requirements align and support the customer’s deliverables.

  • KSP 4: Collaborative Spirit

Team members proactively engage each other to communicate changes, resolve issues, and efficiently complete each activity.

  • KSP 5: Task Interdependencies

Project managers and staff proactively manage and communicate issues that affect adjacent tasks.

  • KSP 6: Rigorous Quality

The task owner ensures that they meet each requirement through unit testing and peer reviews.

  • KSP 7: Risk Management

Project managers and staff proactively address possible risks, communicate and manage risks as they occur to ensure smooth project flow.


Projects consist of a complex network of interdependent tasks. Each task may have multiple predecessors and multiple successors. Changes and quality issues in one task can have an exponential effect on tasks downstream. The longer issues remain unmanaged, the greater the impact on the project’s cost, schedule, and quality.

When properly managed, each activity within a project must be clearly-defined with measurable specifications. The results of each activity need to be verified to ensure quality. Changes that occur during activities need to be communicated to both management and downstream tasks owners to ensure issues don’t propagate.

Managing task interdependency can appear onerous. However, manifesting a culture of clear definition, rigorous quality, and communication will build teams that complete projects faster and with higher quality.


Haerem, T., Pentland, B. T., & Miller, K. D. (2015, July). Task complexity: extending the core concept. Academy of Management Review, 40(3), 446-460.

Jones, G. (2013). Organizational theory, design and change (7th ed.). Upper Saddle River, NJ: Pearson Education, Inc., as Prentice Hall.

Juran, J. M., & Gryna, F. M. (1988). Juran's Quality Handbook (4th ed.). New York, NY, USA: McGraw Hill, Inc.



[1] In formal project management, precedence diagrams are built from activities, not work packages. Therefore, this paper focuses on activities rather than work packages.

3 Top Ways You Can Tell if Your Team is Working Well

3 Top Ways You Can Tell if Your Team is Working Well

  1. Lively – sometimes even contentious! – discussions about the requirements and the stakeholders
  2. Spontaneous peer reviews
  3. More conversations

Number 1 seems to invite revolution – it doesn’t. When teams are coming together in true collaborative spirit to get very clear definitions of work required and the circumstances surrounding it, you will hear it.  Sometimes it’s pretty loud.

And that’s a good thing.

Because questions and answers on topics that matter to the questioners and answerers can get loud.  That’s great – as long as loud doesn’t signal antagonism or bad behavior.  A spirited conversation that teases out what they really meant is a good way for team members to learn constructive communication habits.  Asking, and getting answers, and finding that it’s quite safe to do so can result in greater creativity and more innovative thinking.  Remember the last time you shared an idea with a trusted colleague? Did you ever have the experience when the very act of sharing the idea prompted your mind to tweak it, shift it or change it?

Spontaneous peer reviews indicates that the requirements are clear and technologists and the other professionals on the team are willing to work together to achieve them. It means that the focus has shifted to rigorous quality and away from ‘keep your head down and off the radar’.

More conversations will sometimes start as simply more noise – don’t let that fool you.  As your team builds the levels of internal trust you will find that they, like so many others, will begin to develop team-speak. Team-speak is a kind of short-hand that relies on the ability to trust each other. Combine that with a focus on both clear definition of the subject at hand, and always keeping the customer in mind as the deliverables are crafted, and you’ll have a powerful team dynamic that delivers quickly, well, and with less overall stress.

Which one of these are you seeing in your environment – in your teams?

Encourage open discussion and reward the candid questions that seek to clarify.

Introduce peer review practices on small pieces of work at first. This gives the team members a chance to experience it, see the impact it makes to improve the work product, and grow the productivity level of the team.

Encourage conversation outside of status meetings and formal hand-offs.  Encourage or even direct (at first!) peer to peer conversations when questions arise.  This builds intra-team communication practices and higher levels of trust.

And you can start seeing the 3 top signs that your teams are more productive!

3 Top Ways your Teams can Dive into the Muck of Mediocrity

There is a lot of nodding but not conversation in meetings.

Peer reviews are being rescheduled, postponed, or resisted entirely.

Hand-offs between colleagues signal the first contact between team members other than project meetings.

Kimi Hirotsu Ziemski, MBA, PMP, CSM

Project Management vs Managing Projects – The Issue of Training

A few months ago, I read an article on LinkedIn entitled, The PMP – How it Ruined Project Management which compelled me to respond quickly. In my response The PMP – How it Ruined Project Management – A Follow-Up, I noted a cultural shift in how we recognize and hire project managers (as well as other recognized positions). Early in the new millennium, we (culturally) adopted a process of recognizing excellence through certifications. The problem with certifications is that they are test-based, rather than skills-based. While some believe you can estimate someone’s skills through testing, I believe that, at least in the case of project management, testing is not only insufficient in measuring skills, it also shifts focus away from the more important skills needed by project managers.

Some (many) years ago, a colleague and I contemplated the difference between “project management” and “managing projects”. We concluded that project management consisted of a framework (or structure) for managing projects; while managing projects includes the actions that project managers perform day-by-day. The former is knowledge-based, the latter is skills-based. We discovered that many individuals “know” project management, but still can’t run projects successfully.

To put this into perspective, most people have an intellectual and working knowledge of screwdrivers and other basic tools. Many have an understanding of the internal-combustion engine. Despite this knowledge, very few would be capable of fixing a broken car. Conversely, one doesn’t need a thorough understanding of the internal combustion engine to be a good mechanic, a basic understanding will suffice when combined with sufficient experience.

The separation of knowledge and skill has been well-known and well-documented for many years. In the training business, most instructional designers (IDs) design these two perspectives into their programs. Knowledge transfer can be accomplished through lecture, open discussion, and demonstration. Skills transfer requires practice, so IDs build exercises and role-plays into their programs to allow students to practice and develop their skills.

You might be interested to note that when I first entered the training business in the mid 1990’s, basic project management classes were 4- and 5-days long. Now, they’re typically only three with many companies asking for 2-day and 1-day programs. With some minor exceptions, we cover the same material in all these classes as there is a minimum knowledge set required to understand project management. The difference in the durations is in the skills development. Pure knowledge transfer can occur quickly, but skills development takes time. In 4- and 5-day classes, students were challenged with difficult situations and left classrooms with well-developed skills. To reduce the training duration, IDs were forced to simplify the exercises leaving students with only partially-developed skills. In 2-day and 1-day classes, instructors only have time for knowledge transfer, leaving students with little or no skills development.

With this background in mind, let’s get back to basics.

Knowledge and Knowledge Transfer

We begin with some basic definitions. The following definitions derive from Chen (2010) regarding knowledge and knowledge transfer:

Explicit – Explicit knowledge can be articulated in numbers and words and is expressed using data, specifications, or scientific means. This kind of knowledge is free of context and can be easily shared.

Note: while Chen implies technical learning here, many organizational issues can be trained this way, for example: simple process training.

Tacit – Tacit knowledge is the accumulated practical skills or experiences. It is personal and “deeply rooted in individuals’ cognitive processes and/or ingrained in the routine and non-routine processes of an organization’s unique culture”.

Note: Chen makes a big leap here. The key word is “accumulated”. Certainly, accumulated experience takes time to become “deeply rooted” and involves varying situations.

Individual – Individual knowledge

Collective – Organizational knowledge

These perspectives combine to form four (4) basic types of knowledge (Chen, 2010):


Individual-Explicit              Easiest to transfer, theoretical knowledge

Individual-Tacit                  Action oriented, practical experience

Organizational-Explicit       Written roles and procedures

Organizational-Tacit Routines, norms, and shared beliefs


Note that organizational-tacit refers to the organization’s culture (routines, norms, and shared beliefs).

While Chen offers an excellent model for knowledge transfer, we’ve discovered that complex skills (including project management) require further gradient steps. For example, you can’t expect an individual who just finished a 2-day introductory project management class to successfully manage a 3-year project involving hundreds of stakeholders. In the next section, I outline these steps and highlight challenges associated with each.

Knowledge, Knowledge Transfer, and Organizational Growth

In this section, we examine the path individuals and organizations follow to successfully affect change. We also examine the barriers that inhibit change. This is not an exhaustive presentation as the number of barriers can be extensive. For brevity, we examine the more common barriers seen in practical experience.

For our scenario, we make the following assumptions. First, we assume a single individual receives training in a new topic. Second, we assume the topic is new to the organization. By this I mean that, while the organization may be aware of the subject, it lacks sufficient knowledge about the topic and have few subject matter experts, or supporting practices in place. I will relate the examples to project management.

Step 1:  Motivation and the Belief System

While Chen first introduces “belief” in his organizational-tacit level, our experience demonstrates that this is the first barrier to affecting change. If an individual believes that planning projects (for example) is a waste of time, they won’t want to learn how to plan a project. Motivation to learn a new skill is a prerequisite to any change initiative. The prospective student has to see a benefit to the learning. Here are some typical responses trainers experience in classrooms:

  • This (topic) is a waste of time
  • That will never work here (a very common response)
  • I don’t have time to learn this
  • It’s too difficult

One very common barrier exists when the student was “forced” into the training initiative, especially as a punitive action (“to get fixed”). Frequently, the student will become defensive and actually attempt to prove their punisher wrong by finding every possible reason why this topic is invalid.

True learning cannot occur unless the student is motivated to learn.

Step 2 – Explicit Knowledge

The next step is to introduce the student to the new idea and provide basic information about it. As indicated above, this must include the benefit. This generally is considered the easiest of the steps as it simply requires discussion or reading.

Step 3 – Individual-Tacit – Controlled Environment

Learning and skills development occur in gradient steps. You can’t teach someone quantum mechanics if they haven’t mastered linear algebra. The next step to learning involves practicing the new skill in a controlled environment and in gradient steps. The classroom offers an excellent environment to begin this process, but is generally insufficient to develop thorough skills of complex tasks. The degree of development depends upon the complexity of the task and the effect of the environment. For example, we can teach children how to add two numbers in a classroom as this skill is independent of the environment. One plus one is two no matter where you are.

Projects, however, are complex endeavors involving multiple, diverse stakeholders. While some environmental factors can be simulated in a classroom through role-play and other means, it is impossible to simulate all possible environmental factors in the classroom.

Step 4 – Individual-Tacit – Environment Independent

The student now attempts to practice their new skills in different environments. As the student experiences new environments, they adjust and hone their tacit knowledge and adapt their style to the different environments. As the learning continues, they find common threads that work in most situations, and adaptations that work in alternate situations.

This is where most project management (and I presume other) training fails as the student jumps from a well-controlled classroom environment to the complex and ever-changing organizational dynamic. The problem lies in the gradient steps. While some savvy students might survive “being thrown into the deep end”, most struggle. There are several reasons for this, but most can be categorized as organizational culture. Some common issues include: management or colleagues are unaware or unsupportive of the new actions; time pressures frequently associated with projects; and existing, outdated, or misaligned processes and systems.

New skills take time to develop. The student will likely make mistakes as they develop their new skills, requiring more time to recover. The likelihood of success depends on a supportive environment where such time is allowed, and mistakes are accepted and offered as learning experiences. Mentoring and peer reviews can play a major role and substantially reduce the learning curve.

Step 5 – Organizational – Explicit

At this point, the individual (we can no longer call him/her a “student”) has developed sufficient skills and demonstrated success in multiple environments and situations. As the organization recognizes the success, they begin to develop policies, procedures, and roles to embed the new skills into the organization. This includes training other individuals and managers in the new skills, adjusting processes and procedures to the new practices, and developing support systems.

Step 6 – Organizational – Implicit – Controlled Environment

The next step involves organizational learning. Like the original individual, the rest of the organization’s individuals will experience the same learning barriers. The belief system must be in place (the rest of the organization must see the benefits), and the various individuals across the organization must be given time to adapt their new skills to their environment, make mistakes, recover and learn from them.

Organizational learning generally progresses from the initial group or team outward. The initial team has experienced the benefits first-hand and has already learned new skills by their proximity to the initially-trained individual. Generally, the farther away a group or subgroup is from the original group, the more challenging the transition becomes. 

Step 7 – Organizational Implicit – Organizational Culture

Finally, as more individuals develop skills and practice them in different environments, the new practices become habits; they become the norms and routines of the organization – it becomes their culture.

Cultural Effects that Thwart Improvement

The previous discussion presented the steps to enacting organizational improvement along with barriers that may occur as the organization attempts to improve. Here, we summarize common cultural effects of these barriers and offer solutions.

Time Pressures

Likely the most challenging of the cultural issues surrounding improvement, this issue has only worsened with the global environment and society’s need for instantaneous satisfaction. Every organization is under time pressure and most organizations push employees to deliver fast.

My esteemed colleague, Ms. Kimi Ziemski highlights this issue in one of her most prevalent speeches, The Tyranny of the Urgent. For our purposes, this includes not allowing enough time for learning. Ironically, sending a student to a training class, then not allowing them the time to develop their new skills and recover and learn from mistakes, invalidates the learning, making it a waste of time.

Solutions include:

  • Allowing sufficient time for skills development
  • Allow time for mistakes, recovery, and additional learning
  • Establishing support systems, including mentoring or subsequent training activities

Uncontrolled and Dynamic Environment

Environmental factors greatly affect a student’s ability to develop their skills for complex tasks. Throwing a student “into the deep end” may work occasionally with savvy students, but more frequently overwhelms the student and thwarts learning.

Solutions include:

  • Protect the student from too many new and unexpected environmental challenges. This can be done by the manager as well as other group or team members.
  • Anticipate new challenges and allow the student to plan for them.
  • Allow mistakes and make them a learning experience.
  • Establish support systems, including mentoring, peer reviews, or subsequent training activities.

In projects, for example, a manager may decide to handle the more challenging stakeholders on behalf of the project manager. As the project manager’s skills improve, the manager may allow him to handle more challenging stakeholders.

Gradient Steps

Individuals learn skills in gradient steps. A new project manager, for example, may be able to handle a small project with, say, 100 activities with two team members, but not a large project with, say, 1500 activities and 15 team members. Certainly, other gradient issues exist. Some examples include: level of political complexity, level of client cooperation, number and capabilities of vendors, degree of uniqueness of the endeavor (or project), geographical issues, and many more.

Solutions include:

  • Control the size and complexity of the endeavor
  • As the student improves, push for higher gradients as the student can handle them
  • Establish support systems, including mentoring, peer reviews, or subsequent training activities

Unaware or Unsupportive Environment

Step 1 of our knowledge transfer model involves the individual’s motivation and belief system. If a student is not motivated to learn, they will resist the learning. While savvy instructors can manage the individual in the classroom, when the student returns to their work environment, the same issues may exist in their management, team, and groups. In our scenario, we assumed a single individual was trained, implying the management and team to which they return were not trained. If the management and team don’t understand the new activities of the student, or don’t believe they will be beneficial, they will resist further learning for both themselves and the student.

This is a very common situation. While most managers and staff members are aware of the topic of project management, few realize the depth of complexity, degree of rigor, and level of knowledge needed to successfully run a project. As the student attempts to implement their new skills, managers and staff members alike tend to disbelieve the benefits or need for such activities, and so resist the actions.

Solutions include:

  • Train the managers first to establish sufficient understanding and belief in the topic
  • Train the entire team or group at the same time
  • Allow experimentation
  • Conduct peer reviews

A Brief Organizational Change Model

The previous discussions lead us to a model for affecting organizational change. It is beyond the scope of this paper to present this model in its entirety. More complete presentations will following in subsequent papers. However, we offer an overview and rationale of the model here.

This model is based on multiple works and decades of experimentation and experience. Some works include: Douglas McGregor’s presentation of Theory-X and Theory-Y (McGregor, 1957), Maslow’s hierarchy of needs (Maslow, 1943), Flamholtz and Randle’s presentation of organizational culture (Flamholtz & Randle, 2012), Chen’s presentation of knowledge transfer (Chen, 2010), Hamilton and Bender’s presentation of project risk management and senior management optimism (Hamilton & Bender, 2015), and many others.

Step 1: Establish the Need

The first step in any endeavor involves establishing the need. People are unlikely to change if not motivated. One esteemed colleague, Dr. Zoe Quan notes in her developing thesis, the Dimensions of Impetus™, motivation for change involves three elements:

  1. Degree of Awareness (recognizing the ability of the change to cause improvement)
  2. Degree of Propinquity (recognizing that the change will have an effect in the immediate environment)
  3. Degree of Exigency (recognizing that the change will have an immediate effect)

Step 2: Train the Managers First

This step allows the managers to both understand the impact the change will have on the group/team as well as allowing them to create a supportive environment as outlined above. Key goals for this training include:

  • Recognizing the time considerations needed to support learning, mistakes, and recovery
  • Developing mentoring and subsequent training systems
  • Protecting new learners from unexpected and complex environmental factors
  • Developing a gradient scale system that initially supports success and to allow growth

Step 3: Train the Entire Group/Team Collectively

This action establishes common beliefs and skills across the group and team. While each member of the group or team will develop different skills at different rates, each can seek mentoring or council from others within the group or from the manager. Mistakes will be readily accepted (at least within the group/team) and quickly recovered, reducing the learning curve while allowing continued growth.

Key issues to improve learning:

  • Ensure the training allows sufficient time for students to develop skills
  • Align the training with the organization’s existing culture (to the degree possible)
  • Align the training with existing issues and needs

The size of the team or group is not important. We have successfully developed teams as small as four and as large as over 600. Certainly, the latter offers greater challenges and stronger management knowledge and structure.



Step 4: Continued Support

This step involves two sub-steps.

  1. Create an implementation plan
  2. Start implementing the new skills

The first sub-step takes remarkably short time and need not be perfect. Depending on the size of the group/team, a one-hour meeting with managers and group/team will usually suffice, although add-on activities may follow. One of the benefits of having the group trained collectively is that they will experience a learning curve together, so mistakes are accepted ­– this includes mistakes in the implementation plan. 

Deliverables for sub-step 1 may include (but are not limited to):

  • Establishing environmental controls (assigning responsibilities for handing difficult stakeholders to the manager, for example)
  • Drafting initial tools, forms, and procedures
  • Establishing mentoring systems and protocols
  • Establishing review and further learning initiatives (peer reviews are excellent here)
  • Establish and align reward systems

Sub-step 2 involves actually implementing the changes. Key foundations that aid and reduce learning curves include:

  • Encouraging use of draft forms and procedures
  • Frequent and planned peer reviews
  • Cross-mentoring/cross-training
  • Supplemental training systems
  • Acknowledging and rewarding successes


Affecting organizational improvement is one of the (if not “the”) most difficult challenges a manager faces. Culturally, we send someone to a training class and instantly expect results. While this may occur with knowledge-based training, skills training, especially with complex activities, is more involved and takes more time. Understanding the barriers, complexities, and tools available enables managers to quickly affect improvement with a minimum of risk and pain.

In this paper, we present a methodology for effecting organizational improvement that accounts for many of these challenges. In future works, we will examine these in further detail.

May all your projects be successful!

Michael B Bender, MBA, PMP, CSM

The Value Strategist

President, KSP Partnership, Inc. 


Chen, J. &. (2010). Knowledge transfer processes for different experience levels of knowledge recipients at an offsort technical support center. Information Technology & People, 54-79.

Flamholtz, E. G., & Randle, Y. (2012). Corporate culture, business models, competitive advantage strategic assets and the bottom line. Journal of HRCA: Human Resource Costing & Accounting, 76-94.

Hamilton, B., & Bender, M. (2015). The intersection of senior management optimism and project risk management. Proceedings of the Intellectbase International Consortium. 40, pp. 18-25. Nashville: Intellectbase International Consortium.

Maslow, A. (1943). A theory of human motivation. Psychological Review, 40(4), 370-396.

McGregor, D. (1957). The human side of enterprise. The Management Review, 46(11), 22-28.


Upcoming Events

No upcoming events

Keep In Touch