Archive for the 'PM practice' Category

Create the situation on your project where people will speak.

Project slippages happen on all types of projects. Johanna Rothman, writing for Projects @ Work, offers advice in her article You're Slipping. As usual, Johanna offers practical advice. While she is writing about software projects, projects of all types are more alike than they are not. There's plenty to learn from software and from Johanna. Have a look.

Here's my additional advice: create the situation on your project where people will speak. In most cases, someone on the project has at least had an inkling that something was not going right. Too often the environment is not right for raising the concern…for whatever reasons. When we create the situation for speaking and then we listen we will get the most advance notice that some action is required. In the end it results in less slippage.

Software implementation projects in the business setting can confront a company's business processes. When the project team fails to examine the current business processes the project often fails. Writing in CRM Magazine, Barton Goldenberg warns readers, Business Processes Must Precede Technology. (You'll find the same advice reading The Toyota Way, by Jeffrey Liker.) He urges teams to avoid just adopting the business processes inferred by the software. He goes on to say, Unfortunately, too many organizations depend on CRM software vendors to supply needed business processes. As an alternative, Goldenberg recommends a two-step approach to getting CRM efforts off to a good start:

Pay close attention to the specific business situation for your project.

1. Document the key as-is business processes (e.g., using swim-lane techniques) and make sure to note where they fall short.
2. Review best-practice business processes…that help address these shortfalls and then agree to move as-is business processes to to-be business processes

The author could have been writing about any software implementation project. Good business process can be more important than good software to support it. When there's a mismatch of the business process with the promises to the customers there'll be real trouble.

Why do I write about CRM implementation projects? Because so many companies are implementing CRM software and so many implementations go bad. We can learn something about what makes any project successful by looking at projects failures. Goldenberg's general point is to pay close attention to the specific business situation for your project. That is a lesson that applies to all projects.

It wasn't a happy time for Johanna Rothman this week. She hurt herself in the kitchen making tea. She needed to visit the ER for 4 stitches on her head. She seems to be all right. Typical of Johanna, the injury produced a project lesson, Unanticipated Events Screw Up Schedules. Reading only the subject I thought of the local paper reporting Dog Bites Man. I almost skipped her posting. Glad I didn't.

Always knowing where you'll find response capacity is critical to being able to keep your project commitments.

In the winter in the Northeast we can anticipate snow, sleet, and ice. We don't know exactly when it will occur, but except for the most unusual winters, we know we will incur weather that leads to delays. While we don't put snow "on the schedule", we can add a contingency for snow somewhere "in the plan".

Then there are events like needing 4 stitches that we don't anticipate. In some settings these unanticipated events can have serious impacts on our schedules. When deadlines are important contingencies become critical, especially when those deadlines are tight. Always knowing where you'll find response capacity is critical to being able to keep your project commitments.

Thanks Johanna for reminding us. And do be careful making tea.

Wal-Mart gets a bad rep for a lot of their actions, particularly their influence on small businesses. Might that be changing? FCNow reports one company joining WalMart's CFL campaign.
How many companies does it take to change a light bulb? One. A few weeks back I wrote of Walmart's initiative to sell 100,000,000 compact fluorescent lightbulbs, Will Wal-Mart Change the World Selling CFLs? Let’s Wonder…. It's an ambitious goal even for a firm the size of WalMart. However, to the extent they attract other players, 100,000,000 bulbs just might be a low hurdle.

Kristina Runciman, president of Lifeforce Glass, got inspired:

I was so inspired by the article by Charles Fishman on CFLs that my company is now sending one compact fluorescent lightbulb with every order. We are counting on each customer to try their free CFL and then replace their incandescent bulbs in their homes and businesses.

Great projects are invitiations for participation.

As a wholesaler of giftware, Kristina doesn't have a direct opportunity to benefit from her actions. She won't be making big sales of CFLs. She "signed on" to the larger project of taking care of our environment while taking care of our pocketbooks. Funny thing, Wal-Mart is part of the process. Kristina buys the give-away CFLs at Sam's Club. I can't imagine this was part of the WalMart plan, but what a nice by-product.

I'm liking Wal-Mart's project more and more. Great projects are invitiations for participation. They attract people to join. I'm so curious about how the project is going. Last week I visited the local Wal-Mart to just take a look at the lightbulb section. As reported in the Fast Company article, CFLs are prominently displayed at eye-level along with shelf cards detailing the savings these bulbs generate. Kudos to Wal-Mart and to Kristina for joining in!

Listen up!  If you hear any of these phrases, then it's time to have a conversation with your project manager or your team.  Johanna Rothman writing in the Fast Company blog FC Now recounts overhearing, "We'll try to find the resources to finish the project on schedule."  "Trying" is an announcement of impending failure.  Alarm bells should also go off when you hear these other phrases she identifies:

• We'll try (the one above)
• We'll work smarter (we're working stupidly now?)
• It's just one more change (many phrases with "just" are project killers)
• Let's hope for the best (I wouldn't bank my company's future on hope)
• We'll multi-task (that way we can not make progress on anything)
• We'll find the resources somewhere (where?)
• We'll make do (being resigned to the worst certainly won't help finish a project)

Listen closely on projects.  You'll hear warnings in everyday language…everyday.

Marlon Sanders, the father, the inventor of the two-page website, and one of the more successful online marketers, has three lessons for anyone doing projects.  He says, "People mess up on the really simple stuff."  Here's Marlon's rules of getting it done:

1. Not done equals no dollars.
2. Get one project done rather than 99 undone.
3. Almost done is the enemy of done.

Done is beautiful!

Mitch Myerson, the Guerilla Marketing Coach, has hosted Marlon's 3-minute Getting it Done lesson on his website.  Don't miss it.

Silence Fails, a research endeavor by David Maxwell, Vital Smarts, finds that projects suffer when team members fail to have the crucial conversations they need to have. Projects @ Work picked up the research writing about it in Crucial Conversations.

"One of the keys to successful project management is holding the right conversations on the right issues at the right times."

The article identifies five conversations that project teams need to have to be successful. The findings are the result of research Maxwell did starting with people standing in line. He first asked people what would they do if someone cut in front of them in line. 95% said they would speak up. Then Maxwell secretly watched the same people as someone cut them in line. Surprisingly, the majority didn't say anything. With further research Maxwell identified five crucial conversations that could make a difference on projects. Read the rest of this entry ¶

I just received the latest e-blast from PM Boulevard. They offer short essays on project management practices. The article Communicating Effectively for a Successful Project, by Paula Pierce, Robbins-Gioia, LLC is a good example of their work. It is concise and easy to read and reference. Of course, the title caught my attention. But I was disappointed. Paula's commentary falls short of the expectation set by her article title. Her focus is on the style of communication ignoring the function of communication.

The basic function of communication on projects is the coordination of action. The basic conversation we have on projects is about who is committing to do what by when. Paula says, "Keep (communication) simple." She adds, "Use metaphors and analogy." She goes on to say, "Repeat key messages." All this can help, but only if the basic conversations occur.

The most basic of project conversations is the commitment conversation. It is the conversation where project performers commit to completing something specific. Read the rest of this entry ¶

There is a community of lean construction leaders in Northern California who get together each month at a dinner meeting to help each other with their lean construction initiatives. People from DPR, Turner Construction, Sutter Health, Herrero Construction, and Southland Industries are regular attendees. The group often invites speakers. This coming session will feature Chauncey Bell. He'll be talking with them about breakdowns.

In our work with clients we've come to rely on breakdowns to forward our clients' interests. We also show teams how they can create project circumstances so breakdowns don't result in missing the project promise.

I've written extensively on breakdowns starting with Designing Breakdown-Tolerant Environments [1]. Before I go further, here is a working definition of a breakdown:

An interruption while in the midst of fulfilling ones commitment that puts the completion of the commitment in jeopardy.

I won't repeat what you can read in the series. But I do want to tell you about one change in my perspective in the last three years. If you want a breakthrough in performance, then look to create a breakdown. When I wrote about breakdown-tolerance environments I was speaking about robustness to inevitable uncertainties that can interrupt. But I never intended to avoid all breakdowns. A well-placed breakdown might be just what is needed to get people to shift their common sense.

Unfortunately, I won't be present for Chauncey's talk. However, three people from Lean Project Consulting will be there. I'll get a report from them and post next week. Until then, I'll leave you with this thought from Chauncey,

"You can leave success to good intentions and chance, or you can design the way you make your changes. The choice is yours."

Harvard Business School has a free weekly newsletter called Working Knowledge. Each week they provide three book reviews, three hot topics and much more. In this week's issue is an article excerpted from Harvard Management Communication Letter, The Morning Meeting Ritual, by Marty Linsky.

(I)mbedded within (TMM) are norms and values that are critical for organizations that must deal with difficult issues and adapt nimbly to new situations.

The Morning Meeting (TMM) is described as a senior management process that includes the CEO and all others who report to that person. Linsky's description of TMM shows the power that can be exerted by such a group. Here are his (abbreviated) rules for conducting the meeting:

• Anyone can put anything on the table for discussion.
• These are decision meetings.
• Once an issue is fully vetted, the CEO determines the decision rule that will govern it.
• Changing one's mind, even in the middle of the conversation, is OK, even respected. Not having an opinion is not.
• There are no arguments about fact questions.

I can see TMM process working on complex projects and in PMO's. Good project management practice on construction projects includes an end-of-day meeting to have the foremen declare what work they completed and re-confirm their promises (or re-promise) for the coming day. TMM takes it a step further. As a beginning-of-the-day process it could help the project team stay out of trouble.

"On the surface, TMM is about communication, but imbedded within it are norms and values that are critical for organizations that must deal with difficult issues and adapt nimbly to new situations: an openness to considering multiple perspectives, a willingness to share responsibility for finding creative solutions, and the discipline to move consistently from strategy to execution."

Good project management places a premium on conversation. The Morning Meeting is one way to turn the premium into a habit.

Successful project management is simple…or is it? Lee Iwan (I don't know who s/he is) suggests there are 16 steps to delivering projects successfully. In an article appearing in Lifehack, Lee proposes a Step-by-Step Beginner's Guide to Project Management. If only it were so simple.

The leader-manager sees that the participants are acting as a team — taking care of each other.

These are the 16 steps:

1. Determine the objective and specific desired outcome. Write it down.
2. Identify and organize the people who might be interested or are required in order to bring the project to completion. Ask them to participate, and comment on their level of enthusiasm or belief that the project can or will be successful.
3. Identify a project leader and coordinator, this should be accepted by all involved in the project. No consensus, keep trying.
4. Begin “brainstorming” and create scenarios on how to achieve the desired outcome (this may have be broken down into sub-tasks). Make a date when all this creative thinking will be finished and a written draft can be printed and shared.
5. Identify factors that influence or limit the project that are beyond your control (global economic forces, natural disasters, competition, etc.) and factors that are in your control (capital invested, personnel, prices, etc.). Identify the risks or warning flags that might surface. Write this down.
6. Determine and identify the tools (capital, equipment, machinery), the people (administration, sales, suppliers, customers), and the time required to complete the objectives. Write this down.
7. Organize the people involved in the project. Review the proposed project, the factors of influence, the tools, people and time. Determine the best path, tools, time frame, and write it down.
8. Organize the tasks and sub-tasks in chronological order. Write it down.
9. Ask each participant if they are committed to participating in the project, completing their tasks on time and reaching the final outcome. If there is no commitment, find out why and resolve.
10. Develop a list of initial actions and outcomes that must be started and completed. Identify the responsible parties and dates. Write it down.
11. Request specific (realistic) dates for the completion of tasks, sub-tasks and objectives. Write it down.
12. The leader must follow-up on all dates and compromises. Make this information public to all others involved in the project. Communicate all deliveries of sub-tasks, or lack of delivery with the group.
13. Make certain that the group knows the status of the project at all times, everyone should either be waiting for information or the outcome of an ongoing activity, or actively working on obtaining information or finalizing an activity.
14. If a group member is unable or unwilling to finish tasks on time, discover why and take immediate action to support or replace the member.
15. For any major problems or setbacks, get the group together to work out new scenarios and dates of completion.
16. Celebrate the big milestones and victories.

It's not a bad list. If you only followed Lee's advice, then you would do ok with your projects. However…the author misses a central aspect of projects. Project participants are autonomous. They have the opportunity to say, "No," even though they often go along saying, "Yes." They also are likely to misunderstand what they are asked to do, just like you and I misunderstand what we are asked to do.

Projects require leader-managers who care for the project participants. The leader-manager sees that the participants are acting as a team — taking care of each other. Success depends on those relationships to avoid misunderstanding and to create a project setting where intervening in each others' work is not seen as meddling.

Bob Weinstein has good advice for new project managers. In his article for Gantthead this week, Rookie Rules, Bob starts with four mistakes rookies make:

1. Bad attitude.
2. Make drastic changes without considering possible repercussions.
3. Initiate new projects without getting support from subordinates, peers and stakeholders.
4. Make snap decisions.

Bob follows these four mistakes with "eight tips that can almost guarantee your success on the job." He starts with Be Humble. That's great advice for all of us. Read Rookie Rules for the other seven.

Too many projects are late or over budget, or both. In the March 2006 issue of Customer Relationship Management magazine Jim Dickie reports in It May Cost More Than You Think that about 33% of all CRM implementations take at least twice as long as the CRM vendors told their clients.¹ In addition, 41% reported that they exceeded their budgets for implementation. This is no surprise to anyone following CRM implementations. Far too many have been dismal failures. So how can this be?

In the same March issue, Natalie Petouhoff, Ph.D., attributes CRM failures to our brains, Read the rest of this entry ¶

1. Based on CRM's 12th annual Sales Effectiveness Survey with responses from over 775 companies. [ ⇑ back ]

I've been working with a number of architectural and engineering firms in the last six months. I've been surprised at how so few of them have the habit of conducting project kick-off meetings as their routine. Knowing that, I'm not surprised at the problems these firms encounter with project planning and schedules.

Why have a project kickoff meeting? One manager said, "Geez, there's only 200 hours in this project. I can't waste any of them on meetings." Sound familiar? Before I respond let's review my definition of a project.

A project is a single-purpose network of commitments undertaken by a temporary social system.

People come together on projects as strangers.

I've been challenged in an AE firm when I refer to the project organization as a temporary social system. People say that the "team" consists of employees who know each other. While that might be true, it is also likely that the group is not a team at all. Rather, the people are working on more than one project. The other projects are being done with other people. They get their assignments as work orders. These are not project teams. This is more like sandlot baseball than a well-practiced team.

Face it. Projects are temporary organizations. People come together on projects as strangers. We're not likely to change that. What we can do is make sure people share a context, have intentions that are aligned, and have a relationship that allows them to successfully coordinate action together. I know of no better way than by starting every project with a kickoff meeting.

What would you do in those meetings? Here's my proposal for an agenda.

Read the rest of this entry ¶

Previous in series Next in series

Projects @ Work ¹ just finished a three-part series on People, Process, and Tools written by Alan S Koch. (You need a no-charge subscription to read the articles.) While Koch writes from the perspective of information technology projects his points apply equally well to other projects. These three articles offer a context for building your project organization including the systems you'll use on your project.

• The People Premium
• Processes for People
• The Role of Tools

Koch says what all good project managers know but too often forget,

"People are indispensable, but not perfect…Effective processes enable our most precious resource — our people — to work their magic…Tools are the key to making our people more efficient and effective at executing the processes that support them"

One of my favorite lines from the third article is,

"We do not need a tool for every job."

Koch could have said the same for process. What we do need is to select people, process, and tools that match the challenges of our projects. We certainly don't want more processes or tools than our capable people need. And if you are going to err on having more or fewer people than the project needs, then err on the side of more. Why? You can't improve anything without some slack capacity. Whether or not you plan to do your projects on a lean basis, you'll need enough extra capacity for people to respond to the inevitable surprises and to participate in continuous improvement activities.

Have a look at the articles then take a look at your current project. Do you have the people, process, and tools you need to succeed? If not, then make changes.

1. Hal is on the Editorial Board of ProjectsAtWork. [ ⇑ back ]

The planning system is likely to become more reliable just because you are giving your attention to reliability; it follows the axiom: what gets measured gets done. However, without deliberate systematic attention to the design of the system planning system performance will settle on a plateau.

Planning (un)reliability is a function of (at least) five factors: dependence, variation, uncertainty, system design, and competence. The processes of making work ready, promising publicly, and reporting complete by announcing when you are done are usually sufficient for building competence for operating as last planners within the system. The acts of promising, re-promising, and estimating times to perform build the capability for doing those actions more competently through time. Using the Project Meeting Protocols (mentioned in previous postings) improves performance. But there is generally more to improve beyond what individuals responsibilities.

At least once every three weeks conduct a meeting with the project team to review the accumulated reasons for plan failure.

One significant impact on group performance is the design of the project. For instance, if work has been fractionalized by specialty, then the effects of dependence (you can't start 'til I finish) are increased. One of the usual (greatest) reasons for planning failure is the prior work of others wasn't completed. Often times work can be structured in a way that decouples one person's work from another. That, in turn, increases the reliability of the project. Another common reason is a constraint was uncovered once the task was started. This would point to a failure of the make-ready process of look-ahead planning.

What can you do? Read the rest of this entry ¶

Previous in series Next in series

When doing construction projects there are four usual lead roles: project manager, project architect, superintendent, and client. There are numerous sources of waste. Taiichi Ohno described seven visible wastes¹, Lauri Koskela named making do the eighth waste, Greg Howell and I named not speaking and not listening the two great wastes, but there is a more insidious waste…the waste that arises when people don't perform the roles that have been declared.

One indicator of a good team is team members who take care of each other.

Construction projects' teams are created new for each project. One usual case is the people playing the four key roles don't know each other when the project starts. Success depends on these people playing their roles as they have been declared. Success also depends on these people having trusting relationships. Good projects require good teams. Not just a collection of people. One indicator of a good team is team members who take care of each other.

Read the rest of this entry ¶

1. Overproduction, waiting, transporting, over processing, excess inventory, excess motion, and defects [ ⇑ back ]