What about PM Fundamentalism?

Some who think about Project work are "Fundamentalists". I agree that the basis of their thinking is often justified - there ARE Project practitioners who, by carelessness or ignorance, stray from the basics that are required to deliver a Project successfully. Similarly, ideas like "2.0" can be a useless concept that is adopted in the interest of marketing or of trying to look cutting edge.

There are certain basics for Project success. But, there are some issues with practicing PM Fundamentalism:

• Being stuck in a set of rules (even if we think they always work) does not guarantee that we deliver the best result for the Customer.
• Customers are increasingly demanding - better and faster sometimes mean different techniques and tools.
• Once the basics are covered - Project definition, deliverables, metrics-tracking, budgets, schedule, etc. - we need to be able and willing to move to a higher level of delivery, quality, and speed.
• Why would we limit "what works" to "what has worked in the past"?
• Whatever our PM fundamentals, they sometimes need to be re-evaluated.

I'm not preaching anti-Fundamentalism - that would be fundamentalist in itself. I am saying that many are stuck in a fixed set of rules. Although these rules work in some contexts (and some Customers desire theses rules), lets not paint all Project work as needing to live in the same context under these same rules.

Noticing

Project work success requires awareness.
Noticing what is around us.
Seeing what is happening and what is not happening.
Hearing the spoken and the unspoken.
Observing reactions and non-reactions.
We must act. We will not act on what we don't notice.
Practice noticing. Practice listening. Practice seeing. Practice observing.
Notice and act.

Hierarchy and Project Success

As modern management progressed, it progressed as a command-and-control structure. Probably inherited from the military. The boss said what to do and when to do it and even how to do it. The worker complied with what the boss said - or likely had to find another job. That is still likely the best idea for the military.

Project work has often been the same. Even now, when we claim that work is "more democratic", there is still much of the old structure in place. "I am the Project Manager - you will do as I say!"

Forget the question of democratic, if that's even the right word. If we use the command-and-control structure, we believe that we will produce the desired outcome by our control. We believe that because we are in charge, things will go well on our Projects.

Until it gets too large to control (which doesn't have to be very large). Until we have independent thinkers on our teams. Until we lose our grip for whatever reason.

For Project work, someone has to set the agenda, define the desired outcome, determine the delivery schedule, and establish a budget. When it gets further down into the details, we need to let the team members have the ability to get the work done. They typically will know how best to accomplish what we've laid out for them. They can decide how to do the work in order to get it done on time. Our micro-management of the details only gets in the way of Project success. 

Planning and Ready-Fire-Aim

In business these days, there's an increased emphasis on the need to act before you have everything perfected. That's true in a fast-paced world of business, where the first one to "get it out there" may be the winner. Or, as Seth Godin now refers to it, they need to "ship". Ready-Fire-Aim (RFA) is a spin in the old [firing squad] terminology that said "Ready-Aim-Fire" (RAF). (Perhaps there's a metaphor in there somewhere.)

The business problem is that too many companies get to "Aim" and keep tweaking the Aim to "make sure" they hit an exact bulls-eye. Or, maybe they keeo getting Ready but never get to Aim. Meanwhile, the competition left them behind - since they had Fired long ago. Even beyond that, is the question of what do we do after we've Fired?

Project work needs that same sense of urgency, and many Projects need an improved level of planning. Although planning is critical, we can't afford to be stuck in planning mode. We have to act. We have to put the plans to work. But, once the plans are working, we have to be aware of what's happening. Are we getting the desired results - in terms of quality, time, money, people, Customer, outcomes, safety, etc.?

If we use RFA, that may be okay. But we have to remember to cycle it. We can't afford RFA and then stop. We have to use RFA-RFA-RFA-RFA... Much like Plan-Do-Check-Act. Once the plan is implemented, monitor results and adjust accordingly.

Vocation Quote

"There are many types and kinds of vocation, but the core of the experience is always the same: the soul is awakened by it, transformed or exalted, so that instead of dreams and presentiments from within a summons comes from without. A portion of reality presents itself and makes its claim."

Hesse, Herman
The Glass Bead Game
Page 58
Picador, 1990


 

Staying on Schedule for the Long Term

Weather predictions

I'm not sure what the weather will be in 10 days. I can check the forecast online, but it will only be a forecast. Weather predictors have gotten better, with better information and technology, but they still can't avoid the unforeseen events that can affect the weather - a low pressure cell stalls or moves faster or is diverted 200 miles north or south.

Predicting the schedule for a long term Project can be similar. Will I really finish the work on or before July 12, 2013? Who knows? So what DO we do?

We must manage and measure in the short term. Once our overall schedule is prepared, we have to track the short term to have a chance of getting to the long term end date. In some industries, "short term" may mean one week or maybe a 3-5 week period. (Some highly critical Projects manage schedules on a daily basis - reviewing several times each day.)

Why is this necessary? 

• We can only predict with reasonable certainty our near-term outcomes. 
• Managing the shorter-duration schedule gives us fewer tasks to juggle.
• As work in completed on-time, sooner than scheduled, and later than scheduled, the adjustments we have to make are easier because the number of activities is smaller.

[There is debate about the real value of a Master Schedule. Those in the traditional PM world will argue that they are a necessity. Others say that because of the tricks that can be played in software (forcing an outcome), the long term Master Schedule is almost worthless. Whichever side we take, the truth is the same. Your Master Schedule may be technically and electronically perfect. However, the entire schedule can only be validated as "true" at the end of the project when exact Start and Finish dates have been entered and when all logic changes have been applied.]


Why not just follow the Critical Path?

What about the Critical Path? That chain of schedule activities that represent the least flexible route to the END. If the critical path is correct, a delay in one of the activities in that chain likely will delay the entire project (Yes, I know. We can insert workarounds to overcome the delay, but this can build to other issues).

Some believe that as long as we are staying on schedule with the Critical Path items, we are going to be okay. There are at least two issues with that method especially for long term schedules. First, do we have the "real" critical path or do we have a forced path? (Many managers and supervisors have learned enough about the idea of "critical path" that they like to say that THEY know what the critical path is without being told by any program!) Second, while we are ignoring the work that is not critical, "critical" changes. It changes because something that shouldn't have driven the work gets so off track that it now shifts the definition of what is critical. So, I argue that the critical path can be an important idea, but it is not the solution to everything.

Focus on everything - in the short term

Instead, we need to focus on all of the work - but keep the focus on the near term. The exact method can vary. Many use a simple spreadsheet or a checklist to track short schedules. Then, they integrate the results into the larger Master Schedule. Some don't bother with a separate program or document. They track everything in the Master Schedule software.

It is best to use the Master only as a guide for short term planning and scheduling. The short-term schedule, as a separate tool, can give more detail and can allow workers and managers to have a better understanding of what is to be done and to see what comes next. This is often when the "true" schedule will appear.

An item in the Master may be 25 days long. Using the earlier example about weather forecasting, even 25 days is a long time. If that 25-day task is broken down into it's pieces or steps, we can better answer two questions:
1. Can we really be done in 25 days if everything goes well?
2. When we compile the detailed tasks, how long will it really take?
With this more detailed plan, we may see that we should be completed in a shorter or longer time than 25 days.

Shift the power to a lower level

It's not just about managing the short term work. It's also about who is involved in the work. Should the Project Manager or Team Leader or Area Manager or Supervisor control (or try to control) everything that happens? No.

Allow and insist that those who are closest to the task have some ownership in managing the work. As a minimum, let them participate in the work of expanding longer activities into manageable work tasks. Some will need some guidance. They'll be too detailed or too general at first. They'll learn as they go. Help them. Give them ownership AND responsibility and the results will be better.

So, will it rain four weeks from today? I don't know. But, there is a good chance of it raining tomorrow.

Will IPD and ConsensusDOCS Change Bad Behavior?

A recent discussion on LinkedIn centered on the tendency of Clients (Owners) and General Contractors to hold payments for completed work for as long as they can. This is especially hurtful for smaller companies.

Will the use of new forms of agreement such as the Integrated Project Delivery Agreements by the AIA and ConsensusDOCS change this trend? We'll see.

It's about people and trust - regardless of the form of contract that we work under on construction Projects.

First Ask Why

An interesting question. Of the three - Why, What, or How - which matters most?

What we do or what our Project will do is important. But, there are many more people or companies who can do the What.

How is more critical. Not everyone on every Project will accomplish things in the same way. Some will do it better by their How.

Why is most important. Why delivers the passion of the Project or the team or the company or the business unit. Why explains the reason behind the What and the How.

Read more provocative thought on this here and in Simon Sinek's book, Start With Why. You can see a video explanation of his concepts at Portfolio Careers.

"Chunking" in a Complex Project

With the many possible iterations of interlinked activities in a complex Project (okay, I used that wording to make the Project sound more complex), how can we keep up with all of it? How can we, as Project leaders, both lead and "manage" our Project to success when it involves so many complications?

1. Choose a reasonable number of "chunks" of the work.
2. Watch those chunks.
3. As the details are defined and tracked at a detailed level, manage the chunks.

"Chunking" means breaking the Project into relatively large sections. These sections can be selected by the leader or the Team for the specific Project. There could be chunks based on Team locations (the Atlanta, Dallas, Houston, and Milwaukee teams), when each team carries a portion of the work. Or, they could be more sequential Project definition chunks - initiation, planning, executing, controlling, closing.

Each of these may have its own set of chunks. During "initiation", for example, we might have a group of 5 to 15 critical items or smaller groups of items that we need to watch.

• Initiation
• Team member selection
• Project definition
• Budget finalization
• Schedule initiation
• WBS development
• Procedure development

But, as the Project develops and the definition becomes clearer, we end up with that list or that schedule or that WBS that shows us that 23,591 tasks must happen successfully before the Project is successfully completed. What do we do then? Do we keep the Project going well by keeping tabs on each of the 23,591 items? We can try. Some people do seem to try this. They try to manage a 23,591+ item To Do List. I understand the issue of being "detail oriented". But, as the Project leader, detail orientation at this level will keep us so busy with tiny details that we will miss the overall goal of the Project. We will get distracted by item 26 and 418 and 680 and 2,006...

Then, while we're focused on one of those, many others are still proceeding and something larger may be happening that causes the entire Project to derail.


Now, some will likely argue that we can still watch each detail, because, the sequential nature of most Projects means that 23,591 tasks won't be really happening all at once. Depending on the time available, there could only be 2,000 per month or 1,000 per month, etc. Still too many items to manage. Remember, even if we could manage those items, the interactions lead to the real complexity. If we have many items, the possible combinations of interactions grows exponentially (or factorially!).

1. Start with chunks.
2. Refine the chunks as the Project develops.
3. Keep watching the chunks.

That is a critical part of managing complexity.

What is a Complex Project?

We have different concepts of complexity. For someone who says "I'm not good with math!", finding the area of a simple, right triangle is complex. Sometimes complexity is about viewpoint ("I'm not good with math!"). Sometimes complexity is about your personal stress level (what causes you to experience stress). So what is Project complexity?
 

A Complex Project involves a network of numerous tasks* with a wide variety of interactions and inter-dependencies.

(* Although I've used "tasks", this could also be other Project elements - resources, people, locations, etc. I've used tasks generically under the assumption that even if the complexity is caused by numerous "locations", these are still represented by "task interactions and inter-dependencies".)

Mathematically, as the number of tasks grows, the number of possible interactions grows at a rapid rate. For a small number of tasks, say 3, we can easily write out the combinations that are possible: (a,b,c) (a,c,b) (b,a,c) (b,c,a) (c,a,b) (c,b,a). But, even at a small number like 3, we are reaching our limits of keeping track of the possibilities by memory. Expand that to 2,000 or 15,000 distinct tasks and we get a real feel for the meaning of complexity. Obviously, this explains why Projects with many tasks require sophisticated software for tracking schedule tasks and in most cases for cost tracking as well.

For Project work, the question of complexity also has to assume some base level of Project competence. Otherwise, we're debating the meaning of complexity. So, in the simple definition above, terms like "numerous" and "wide variety" have to have some boundaries.

If a Project involves a common set of sequential tasks that we've encountered numerous times, it's no longer truly complex for this discussion. Although we might not be able to mentally track all the combinations of tasks, we understand it from experience.

So, for a clearer definition, a truly complex Project must have some additional issues. The issue could be one of the following sets:

1. The set of tasks is an unfamiliar one. The unfamiliarity creates uncertainty about the results.
2. The tasks are familiar, and the results of a failure in the interactions is known to result in Project interruptions.
3. The task are familiar, the results of a failure are known, and the number of interactions is very large.

We could continue to expand that list but these are basic. So, if this is a Complex Project, what do we do to improve our leadership and management of a Project like this? 

Wind Power - Even Those Who Are For It Are Against It

To hear the general press these days, it seems everyone who is anyone is in favor of alternative energy generation. Even many of the traditional utilities are developing alternative energy sources and forming divisions or separate companies to focus on it.

But, even when "everyone is pro alternative energy", some are still against it when it comes to having it in their state or area. That seems especially true for wind. (See here and here). Arguments seem to range from the "impact" of the turbines (birds, ecosystem, visibility) to issues of competition for markets.

Project People - Are We All the Same?

This is not about diversity in the usual sense. Not a question of ethnicity (although it could be) or national origin (although it could be) or race (although it could be) or any of the other uses of the word that are "normal".

For some Project work, this will be heretical. For some Customers, this will seem foolish. For some Project leaders, this will be insane. But, here it is anyway.

First, a mental excercise.

1. Gather your team together. In reality or mentally or by reviewing a list of their names.
2. Do they all have similar work experience? Similar previous companies? Similar previous Projects? 
3. Is their education level similar? Similar degrees (or lack of degrees)? Similar schools?
4. What else is alike about them? 

Often, in doing this exercise, we often see that they are homogeneous.

• The software Project team has similar coding experience and they've all worked on similar development Projects in the past.
• Members of the accounting team all are (or are in the process of becoming) CPA's.
• Everyone on the manufacturer's Project team has 10-15 years of manufacturing process improvement using the Toyota Production System.
• The Customer likes her construction team because they've all built projects just like hers before - at least 5 times.

(Objection - before you race ahead, YES, I want an experienced physician to diagnose my illness and treat it - a real Medical Doctor from an accredited school with the proper Board certification, etc. YES, there are certain areas where exact experience and an exact background is not an option.)

For many of our Project teams, life and death are not the issues. Have we limited the results of the team by limiting our thinking about who is and who is not "allowed" to be on the team?

Here are some things to consider:

• Could someone who has demonstrated leadership in other areas, have a leadership role on your Project? Why? or Why not?
• Can that recent graduate from art school who hasn't been working in construction for 30 years, but wants to build, contribute to your construction Project?
• How can the woman that always has what seem like weird ideas (usually because that's NOT how we do it here) make your Project better.
• Who says that a junior level engineer with 1.45 years of experience can't add to the value of the team?

So, if we're all the same - same background, same experiences, same industry, same schools - are we getting the absolute BEST for our Projects?

Next time, when there an opportunity (how about now?), try someone "different".
Someone who doesn't look that same.
Sameness leads to boring.
To mediocre.
To nothing new.

Tennessee Flood Waters

You've probably seen the intense flooding that Nashville and much of Tennessee have experienced recently. First, it was amazing to actually watch nearby as a "normal" creek filled an entire flood plain. As I watched, you could see debris and miscellaneous things floating by in the water. Some neighbors became concerned as the water covered the nearby bridge and road - and then approached their back doors. Those waters never made it to the door over the two days that the creek became a river.

But, then the wider picture comes to view. Others were not so lucky. You move up to an aerial view or to a local reporter on the local news and you see the power and destruction that the water could cause. Houses and commercial buildings and vehicles submerged in the water. Even the tragic loss of life, in some cases.

It's easy at first to just see the local events (the creek becoming a river) and watch in amazement. Then, as you expand your view beyond your tiny micro section of the event, you see that it was much more than amazing. It brought suffering and hardship and trouble. It brought loss and fear and yearning for drier times.

But, in the midst of that, you also saw hope and relief and neighbors. I didn't see a single story (in the several days of non-stop news) where anyone complained about the loss of their stuff. In fact, most seemed to realize that when it comes to life and death, the stuff doesn't matter. There were not any scenes of people rescuing their TV or their sofa. Only photos and valuable papers and things that couldn't be replaced. Although there were stories of folks who had very recently bought their "dream house", they weren't complaining about the loss of the house.

Many people experienced some very difficult times. But, they have realized that the stuff doesn't matter. It's the people who matter.