Project Basics - 5 Things

Greg Alleman at Herding Cats often discusses the complexities of complex Projects. Occasionally, he comes back to some very basic concepts that everyone doing Project work should understand.

Recently here, he outlines 5 Basics:

Where are we going?

How do we get there?

Do we have enough time, resources, and money?

What could get in our way?

How do we know our progress?

What other basic question would you ask to define the simplest view for your Project?   

E+R=O

It's a formula used by some Personal Development people:

E+R=O  which says Experience + Response = Outcome

It's used to indicate that individual outcomes in life depend on our response to what happens - not on what happens.

 

You can also apply a form of this to Project work. In spite of our planning, and even our wishing and hoping, things happen during our projects that are not as planned and are not our desired results. So what do we do?

We can fret and worry. We can cry and moan. We can curse the plan or the event or whatever it is that we want to blame. The problem is that none of these will solve anything. None of these will help our project.

Instead, we have to refocus and decide how to best respond to whatever goes off track.

Offline for Awhile - Back Soon

More Project Schedule Options - Tom's Planner, Liquid Planner, and Basecamp

I'm not a software reviewer. I let the professionals do that. But, I do appreciate learning about different software that can help do Project work. Many Project folks are stuck with (or stuck on) P6 and MS Project. That's not meant as a slam to P6 or Project. That's just how it is in the corporate world - especially in some industries. Sometimes, you don't need that much power. Sometimes, you need to try something new. Sometimes, it helps to use something different. Here are a few options to look at - Tom's Planner, Liquid Planner, and Basecamp:

Tom's Planner

Tom's Planner advertises itself as a tool for those who need something less that the super powerhouse programs (my words) but want something more than an Excel-created schedule. You can try it in beta for free.

Liquid Planner

Liquid Planner and other programs are also designed for collaboration. I know. Some of you just winced at the idea of a schedule produced by committee. But, collaboration is not about a committee, it's about agreement on the how and when and who of getting Project work done.

Basecamp

Basecamp is another option. It's one of several options offered by 37signals. It also has an emphasis on collaboration and communication. Not just on charts and graphs.

Expand your thinking and your experience and your skills by trying something new.

Blog Style Note: We vs You-and-Me

This blog has been written as a conversation. As if "WE" were talking about our work and Projects.

I plan to begin shifting to a more You and Me tone from now on. Not changing away from conversation - simply changing the way we :-) are addressed.

When Does the WBS Become Just BS?

Structured Projects include a Work Breakdown Structure (WBS) to assist with tracking. This is a good structured way to disassemble a Project into it's components. It's true that you can't really manage a giant amorphous blob. However, does WBS ever evolve into just WBS?

A Project Scheduler once spent two weeks developing the BEST schedule activity numbering scheme. He tried several combinations and two weeks later, he finally picked one.

That kind of thinking leads to wasted time and resources. The same can happen with developing a WBS. Since the lower levels can cover minute details, a detailed WBS on a large and complex Project can lead to thousands of items.

• On the one hand, this seems good - you can track every dollar (and penny) and you can schedule every detailed work item. 
• On the other hand, this is not good from a practical viewpoint. Theoretically, not everything has to be practical. However, Projects do not typically live in theory.

The Practical Issues with Overly-Detailed WBS's

If the only activity involved in Project work concerning a WBS was the development and definition, it could be as long and detailed as possible. But, once the WBS is defined, one of its functions is to provide a tracking mechanism. The tracking of complex details leads to some practical things to consider:

• A usable CPM schedule includes links between activities (WBS items) and relationship definitions. The more detailed the WBS, the more possible relationships and links. This means both more work is establishing the schedule and much more work in maintaining it.
• A usable cost-tracking system should be accurate. But, as an extreme example, if I break down the labor activities on a Project into 15 minute increments, I both create a tracking nightmare (and a loss of productivity because of the level of tracking required) and an accuracy issue. This would be so detailed that it takes too much time to track, leads to gross inaccuracy, and has no value.
• Similar for a productivity system - too much detail will lead to inaccuracy which will lead to meaningless metrics.

If the WBS is overly complicated, it is worthless for the Project. It just becomes WBS.

Be Different and Be Creative

It's sometimes easy for Projects to reject creativity. In this video, see some good ways to reject creative ideas. Thanks to Youngme Moon via YouTube.


Go and be Different.

Always Do What the Customer Wants?

We say that delivering a successful Project includes providing what the Customer wants. But what if we see something better for them? Should we:

• Do what they ask and keep quiet?
• Recommend something that is different and better but don't push too hard?
• Suggest and remind and show and deliver a better result even if the Customer is resistant?

Most of us are likely to do one of the first two. Most of us are afraid that the third option will lead to the end of the Project (for us, at least), ongoing conflicts with the Customer, or at least a bad reputation. Which is better?

Better is an issue of perspective and belief

If we believe it's better to get along and go along, we'll do that.

If we believe it's better to suggest and recommend (and then to think "we told them of a better way", if the Customer turns down our idea), we'll do that.

If we believe that the Customer matters AND that our responsibility to the Customer is to deliver a superior Project even if it isn't what the Customer expects, we'll do that.

Which is riskier? It depends on your perspective of Risk. And your belief.

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.

Make Something that Matters

If you've read Hugh's book Ignore Everybody or read some of the cards on his site gapingvoid, you know that he is not conventional. Sometimes he may be hard to interpret.

The card above can be about Project work. How it should be. It should MATTER. Even the sometimes mundane and seemingly boring parts that we hate doing. In the end, our goal is to move the Project to completion. To give the Customer something that matters.

Go do work that matters on your Project.

Selling Your Project in 15 Seconds

You have a great Project idea. You've done the work to prepare. You know what it will "cost". You know the people that must be on your Team. But, you still have to sell the project.

Maybe you've already submitted your plan to a decision-maker. They've said: "If Ms. X will go for it, I'll go for it. But, I haven't had the time to meet with her yet."

Then, on Tueday afternoon, you get into the elevator. At the next stop, Ms. X gets in with you. You have 15 seconds. How will you pitch your Project to her? Are you ready? Will you keep quiet?

Here's a link to a site that focuses on how to make that 15 second pitch to sell your Project. At 15SecondPitch.com you can learn more about how to make your Project pitch. Or how to make a short pitch for any idea. Try it and see. Then, practice. You'll be ready the next time you see your Ms. X. 

Mind Mapping for Customer Relationships

Projects have Customers. Internal. External. Someone needs and wants the output that our Project will produce. Look at how one company is using mind maps to improve their relationships with their customers.

The Dangerous Middle

When we start a Project, we're usually interested and excited and focused. When the Project is wrapping up, we often have the same intensity - "we're close to the finish - keep at it!".

But, sometimes the middle can seem different. Things are going as planned. We are on budget. There are no recurring problems. So, we relax a bit. The work starts to seem a little boring maybe. After all, when things are going well, we don't have the excitement and drama that we have when there are "problems" to solve.

That's when things can drift. We relax a little too much. We start to put things off. We start to ignore the basics. We weren't TRYING to cause a problem. But, when we let up too much, problems start to appear.

Don't let up in the middle. Keep the focus. Get things done early. The Dangerous Middle can lead to bigger problems if we ignore it.

Can You Descibe Your Project on One Page?

Project plans are often many pages in length. Sometimes, that is a necessity. The Project is complex. The details are important. The Customer expects to see a long, detailed plan. Aside from the "have to" situations, however, can a Project be described on just 1 letter-sized page (written in a font size that is readable!)?

Being detailed and being able to communicate details in writing are valuable. Being able to boil it down to 1 page takes practice. It takes editing. It takes some thought. It takes the ability to see through all the details to the heart of what is really important.

So what would be in this short plan?

• The purpose - in a few sentences at most, what will be achieved by successfully completing the Project?
• Who will benefit by the completion of the Project? Who is the Customer?
• What is the time frame for the Project - when does it start, when is it scheduled to be completed?
• Who will work on the Project? The Company. The Team. The Division. Whatever group or person.
• Is there something special about this project? Is it a one-of-a-kind? A first? Number 648?
• How will the project execution happen?  Careful! This is where the details want to be written down.

For a specific Project, a different set of items might be important. That's part of the exercise. If you only have 1 page, what is critical? What must be said? What details can be excluded?

Try this on a new or existing Project. You might learn more about what critical factors need attention. Attention to detail is often important - unless we get caught in the detail and miss the larger picture.

Not a Pretty Project Picture

This is a graph of the US BLS Employment statistics for Construction of Buildings. This roller coaster graph is not only a picture of the working lives of many Americans, but is also a picture of many great Projects - delayed, suspended, or canceled. Delayed works of architectural and engineering wonder coming to life. Suspended dreams of great craft work. Canceled plans for more great Projects.

How is This Moving Project Work Forward?

Projecting Forward is supposed to be about moving project work forward. Most of the topics so far are very basic. So, how does that move anything F-O-R-W-A-R-D?

Well, that is a good question. I asked myself that question. Moving forward has to start with a foundation of some sort. So, to answer my own question, I'm working first on the foundation and will move into more forward thinking items as I go.

Meanwhile, if you want to think ahead some, read here.

Are We Planning for Planning's Sake?

Each project starts with some version of a plan. Maybe several different plans. We're trying to decide - beforehand - how to successfully get to the delivery stage on a Project.

 

However, what happens once we start executing? We start out to do the work and something happens. It doesn't go as we planned it:

• Something is late.
• Something is out of sequence. 
• Someone does something completely "off the plan". 
• The Customer changes the requirements. 

It makes you wonder if all this "planning" was a waste of energy and resources.

 

No, it isn't a waste because it isn't just the plan that matters. What matters is the thought and debate and editing and reviewing and rethinking and re-editing that are required before we get "The Plan". It's in the preparation of the plan that we become able to handle the changes and the unexpected.

If we hadn't done the work of planning, we wouldn't have a clue where the Project was supposed to go. We wouldn't know if we were off track. It's the process that does it. The real work to benefit the Project is in the wondering if the plan is right and then deciding to scrap the original plan and re-write it. That's the type of real work that makes us ready for the failures and mistakes and unexpected events that happen as we proceed with the Project execution.

So, planning and plans are necessary Project work. But, if things get off track after the plan is published, we are ready - because we did the necessary work at the beginning.

Monday Pause

We do get caught up in life and work and Projects. 

Pause today and consider this poem from William Henry Davies.

(Thanks to Tom Peters and here.)

Leisure

What is this life if, full of care,
We have no time to stand and stare.

No time to stand beneath the boughs
And stare as long as sheep or cows.

No time to see, when woods we pass,
Where squirrels hide their nuts in grass.

No time to see, in broad daylight,
Streams full of stars, like skies at night.

No time to turn at Beauty's glance,
And watch her feet, how they can dance.

No time to wait till her mouth can
Enrich that smile her eyes began.

A poor life this is if, full of care,
We have no time to stand and stare.

Experience, Talent, and Ability

Many think that experience is the most important thing. I've written some commentary on that here.

Talent can easily trump experience. Only experience that demonstrates talent has value.

Ability can easily outweigh experience. Experience must demonstrate ability and an increased ability to have value.

Aim for Talent and Ability.

We're All in Sales

I used to hate the idea of sales. That's mainly because I viewed it as trying to get someone to buy something that they didn't really want. Sometimes I still think that way - except with a newer understanding. It's when I don't believe in what I'm selling that it's hard to be motivated to sell it. If I don't believe in my company or product or service - or myself - it's hard to be convincing in trying to persuade someone to "buy".

Selling doesn't always involve an exchange of money. It is also required for other things - ideas, position, time.

On our Projects, like it or not, we're all in sales. That's not a new idea, but it is a true idea. I know that some of us "just want to do our work". But, even if we "just want to do our work", it takes some sales ability. In order to be able to do our work, we have to sell someone on the idea of letting or allowing us to do that. But, if we don't believe in it, we won't be very convincing and probably won't be convincing enough to sell the idea.

More than that simple example, we have to sell in several areas of Project work:

• The Project Itself - at almost any level, there is someone who has to agree with the idea of the project itself. Seldom does the go-no/go idea come from a single person. We sell the Project to an outside Customer or to someone within our own organization.
• Working on a GREAT Project - someone has a GREAT Project. We want to be on that team. We have to convince someone (or maybe several someones) that we should be part of that GREAT Project. We sell our skills and talents. We have to demonstrate the value that we can bring to the Project.
• Getting the Best People on a Project - great people are in demand. Everyone may want them on their Project. To get these folks on our team, we have to sell them on the idea of the Project so that they will want to choose our Project over other choices. We may sell the idea to them several times in several ways before they agree.
• Other Project Resources - we sell others on the idea of using space, or time, or equipment, or materials, or other Project resources. We don't always get them just because we say we need them for the Project.
• Selling Ideas within the Project - once the Project is rolling and we are on that GREAT Project with a GREAT team, the selling is not over. If we are leading, people on our Project are not going to blindly follow our ideas. If we are at the lowest level of experience and "ranking" within the Project, we have to convince others that our ideas are worth pursuing.  Whatever our role, ideas have to be sold.

Every day, we are all in sales. Even on Project work. We can't sell it well if we don't believe in it. Now, let's go sell something for our great Project work.

Mapping Information for Projects

Mind maps are an increasingly popular visualization tool for collecting information or planning. (Get the Wikipedia story here, see more at the Mind Maps blog here, or the mind maps software blog here).

Here's a sample of a hand-drawn map on the left. If you aren't familiar with these, they start with a central idea or subject. Then, they branch out with subtopics off the main idea. The branches can continue as far as you have paper (in the hand-drawn version).

 

 

We can use these for Project work such as:

1. Outline new ideas for a new project(s).
2. Brainstorming answers to a problem.
3. Outlining a book or project report.
4. Recording notes from a meeting.
5. Explaining a concept.

The software version is similar but more symmetrical. (Both free versions and purchase versions are available online. If you are interested in the software version, check the mind mapping software blog for more info.)

These make a better public presentation tool and are better for those who prefer software to hand-drawing.

The question becomes, what's the benefit of using these maps for our Project information?

It seems the answer depends on a few basic things:

1. What kind of learner are you?
2. What's your preferred method of explaining or notetaking?
3. Can you easily learn new ways of learning?

I've used both the handwritten and the software versions. I won't say they are the golden answer to all questions and problems, but, for me, they are a useful way to visualize information. The hand-drawn version requires only simple tools - paper and pens or markers (using different colors does help with visualizing) - and is obviously portable. But, if you are at your computer, the software version goes together quickly also and can be printed in color.

Try one out and see how they can contribute to your Project work.
What other unconventional tools do you use?

Scheduling - Purists vs Randoms - Obvious Lessons

In ProjectWorld, scheduling can create massive controversy. Much of the debate is between "Scheduling Purists" and the opposite - I'll call them "Random Purists".

Scheduling Purists often feel that whatever is generated on paper (or on screen) is what will happen, at a certain time, and in the exact required sequence. They are often disappointed and amazed when the actual execution of the Project happens in some other order of events or when a specific task goes (apparently) unnoticed long after its scheduled start date.

The eXtreme version of the Random category is just the opposite. They want to do what they want to do when they want to do it and it will "take as long as it takes". Or, perhaps when they are "trying to be part of the team", they don't say it THAT way, but they generally ignore what's planned since they believe a different sequence or set of activities is best.

Whenever these two are together on a project, they will obviously create friction. Friction can be good, but this usually creates friction so hot that it will burn through a Project and leave a scar.

So, is one of them right and the other wrong? Not really.

A few points from this two-sides-of-the-coin extreme are these :

1. One person (or one small group) shouldn't decide what will be done and when. As many participants as possible should be involved in the process.
2. In spite of best efforts at the beginning to define what will happen when, something will likely change. That statement is not a way out for the Randoms to throw away the schedule and do what they want. Think of it like this - we say what we plan to do today, in the next hour, with some certainty. The shorter the time-frame, the better the certainty.  However, trying to say with certainty what we will do in 2 months at 8:00AM or in 14 months is reaching, to put it mildly.
3. Plans and schedules have to be somewhat flexible and should be expected to change as we move further away from "Start Here".
4. Items 1-3 are not excuses to throw it all in the trash. The Customer always has a desired timeline for completion of the work. The old sayings "You can't hit a target you can't see" and "If you don't know where you are going, any road will take you there" come to mind.
5. Friction about some details and plans leads to better plans. But, neither ignoring the schedule because we choose not to "own it" nor demanding that the original plan be followed at all costs will benefit the Project.

Project schedules are typically necessary. It might be a list. It might be a 2,376 item graphic. It might be milestones on a calendar. Whatever form it takes, we can expect that the schedule that's developed early in the project will need some adjustment as we go along. And, we can expect that someone working on the Project who ignores the plan and schedule will generally fail to deliver.

PROJECT-ing Forward

There is some debate in the Project community. The wider community.

Some vote for PMI, PMP and all the other letters.


Some vote Lean and Agile and 2.0 and the "new way".

It can be easy to pick a side or easy to go buffet style and take some of each. (That will be heretical to some who are strongly on one side or the other.)

Better still, when we think about better or great Project work, think about how we can move the discussion forward.

Not stuck in any time period or stuck on any method. (Sure, certain fundamentals don't change. We can debate the fundamentals another time.)

If we must get stuck, let's get stuck on PROJECT-ing Forward.

Doing something new. Doing something better. Learning every day. Making mistakes and trying again.

But, don't stay stuck. Move ahead.

Who Manages Time?

Time - "A continuous, measurable quantity in which events occur in a sequence proceeding from the past through the present to the future."

In doing Project work, we manage people, money, and materials. Those are often thought of as the basics. Within reason, we can get people and manage what they do for your Project. We can get money (okay, let's not argue about this one in the current lending climate!) and we can manage it. We can get more materials and we can manage them.

But we can't really get more time. And, how do you manage time?

MORE TIME

1. Time is a different resource for a Project. Like the definition says, we can measure it. It only happens in a sequence.
2. Customers need the Project completed in a FIXED amount of time - by a certain date. Very seldom is it their preference, even if they add to our Project Scope, to give us more time.
3. Every work day, we only have a fixed amount of time.
4. Even if we excel in productivity (doing more in less time), Project tasks will take some amount of time.
5. One task may wait for some time before another is completed so that it can start or finish.
6. We may have a schedule that says something will be done in a certain amount of time. If that something isn't done as planned, it doesn't really get more time - it uses time from something else - that can't get more time - that uses time from something else - on and on. I know, it's not all that sequential.
7. We don't really ever get more time.

MANAGING TIME

So, how do we MANAGE TIME?

1. We don't really manage it.
2. Sometimes it seems to manage us, instead.
3. We can only treat is for what it is - a scarce resource (usually) that is part of the whole Project picture.
4. We can manage the USE of our time. Deciding what to do today and in so doing deciding what not to do today.
5. Time needs attention. 
6. We have to stay aware of it. Late is never acceptable on a Project. If you are late, sometimes everything else that went well is forgotten. All that is remembered is - "She was late". "He didn't complete it on time."
7. "Better late than never" - is a lie. At least for Project work. So, though we can't really manage it, we must make the best use of it on our Projects.

YourSelf as a Project

Interesting post titled "42 Practical Ways to Improve Yourself" by Celestine Chua over at Lifehack. (She also has her own blog about Personal Excellence.)

To keep improving our Project work, we have to also make a Project of ourselves.


Notice a few of her personal items that also sound like Project work:

• Overcome your fears
• Level up your skills
• Get out of your comfort zone
• Put someone up to a challenge
• Identify your blind spots
• Ask for feedback

42 ways to do something is both interesting and overwhelming (how will I ever do all of those?). We can pick a few that strike our interest and work on those first. Then, go back for more - for us, for our Teams and for our Projects.

3 Quotes for Project Workers

Heard these a thousand times? Think about them now in the context of your current Project work:

"I have been impressed with the urgency of doing. Knowing is not enough; we must apply. Being willing is not enough; we must do." Leonardo DiVinci

"The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark."  Michelangelo

"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood, who strives valiantly; who errs and comes short again and again; because there is not effort without error and shortcomings; but who does actually strive to do the deed; who knows the great enthusiasm, the great devotion, who spends himself in a worthy cause, who at the best knows in the end the triumph of high achievement and who at the worst, if he fails, at least he fails while daring greatly. So that his place shall never be with those cold and timid souls who know neither victory nor defeat.”  Theodore Roosevelt

Now, go take on your Project with new vigor!

Make Better Project Connections


Sometimes we talk about Projects as if they are objects that live on their own. Projects never see a start or a completion without people working on them. Every Project ends up with at least one Customer (someone who receives or experiences the result of the project) and an Executor (at least one person who carries out the steps needed to deliver the project). Most of us, however, never work on such "simple" Projects.


Most of us work on Projects that have more than one Customer - often a group of diverse, complicated people who are expecting to experience the benefit of the Project work. Most of us work on Projects with a team of folks doing the Project work with the same issues - they are varied and complex and temperamental and all the rest. To deliver the Project successfully, everyone on the project team needs to be focused on connecting in a way that leads to the desired project results.

To connect, we have to be able to communicate. We have to be able to ask, answer, listen, observe, notice, respond, anticipate, understand, consider, and debate. Some people avoid this part of Project work. They'd rather build or code or make or write or do. You've probably heard that saying that "Work would be fun if it wasn't for the other people involved." 

But, connecting deliberately is a non-negotiable part of Project execution.

How are you doing at connecting? At doing your part to see that you and others working on the Project are asking, answering, listening, observing, noticing, responding, anticipating, understanding, considering and debating for the good of the Project? 

A Few Project Management Realities

Over at Reforming Project Management, Hal uses the recent issues about Toyota vehicles to connect their situation to Project Management. He pointed out some project realities that are worth summarizing:

• There is more that can be known than we have the ability to know.
• Either accept that as the basis of how we design our project environments or ignore it. 
• Project plans can't predict what will happen in 3 weeks, let alone 3 months. 
• Our plans must change. 
• People will make mistakes. 
• People will learn something unanticipated. 
• The circumstances for our customers will change.

But Hal doesn't leave it at that as if to say "Oh, well. Stuff happens!" He wraps it up with:

Manage in a way that every person on our projects and those concerned for our project success observe, speak up and share freely and quickly what they learn. 

Regardless of your views on the Toyota issue (pro or con), Hal links that issue to some important Project advice. You can see the full post with comments here. Thanks, Hal.

Project CHOICE
To do more great Project work, we have to choose more of the Projects on which to focus our time and energy. Great Project work will look different for different people. 

If you haven't been doing this in the past, look for a Project that:

• Has a positive impact on your company, department, or industry.
• Benefits your neighborhood, community, or city. (Every Project doesn't have to be one that provide monetary benefit.)
• Gives you a chance to grow your skills and experience.
• Grows your people skills by managing a larger or more diverse workforce.
• Lets you collaborate on a great team.
• Stretches you in some other way.

If won't be easy to stay on a path to more great Projects. Often, it will require more work - more searching, more networking, and more changes. In a large organization, it may mean more internal competition and more internal positioning. In a small organization, it may mean changing employment or constant internal selling of the idea of great Projects. 

Overall, doing great work on Projects will make you more satisfied in your Project and work life. You'll look back later and see that you really made a contribution rather than just floating along through life.

Experience and REWORK

I've worked with many older and seasoned folks over the years on projects. Often, they had many more years of experience than me. Some of them reported to me on projects. 

One sad thing I noticed about many of these (I won't say all, but it was a common theme), is that they liked to talk constantly about a previous project. Some were hanging on to that one project they had worked on 10 or 15 or more years ago. They wanted everything on the new project to relate directly to that old project. Usually, the conversations were about how they had done it differently on that old project and why couldn't we do it like that on this new one? 

I don't know your experience in this issue. But, for me, these folks were deliberately placing themselves in that "how we did it then" category. It didn't matter that techniques had changed, methods had changed, the law had changed, or that anything else had changed. They wanted it the way it was. 


I thought of this recently in reading REWORK by Jason Fried and David Heinemeier Hansson, Founders of 37signals. In their book (highly recommended for project thinking), they have a section titled "What Does 5 Years Experience Mean Anyway?". The subtitle explains their point - "Year of irrelevance".


It isn't the time you've been employed that matters in the end. It's what you did with that time. Many of those I mentioned above were still living in the past. Many more still are today. To be able to do good project work, you have to learn and grow. Sure, those old experiences can be valuable as lessons for work and life. But, those experiences can't be your whole life.

If you're stuck there, I say you should get out now. Learn about your work from a new perspective. Learn about what's happening in other industries. How are other people and other companies changing as things change?

If you are already advancing, what keeps you moving?