Archive for the 'leadership' Category

I've been meaning to write about the art of project management for quite some time. No need for me to do something that Scott Berkun has done so well. His book, The Art of Project Management, is unlike any other book on the market. Scott understands something that most project managers fail to grasp. Developing proficiency is not a matter of knowing techniques and engineering. Proficiency develops with practice, by making mistakes, taking on challenging work, and by learning at the feet of others. Read the rest of this entry ¶

he motivationists would have us believe that people do what they are rewarded for doing. Bonus programs, salesforce commissions and incentives, and promises of raises and promotions are part of the everyday way companies organize themselves in hopes of getting higher performance from their employees. My own experience is different from that (and numerous studies reported in HBR are consistent with my experience). Neither the carrot nor the stick get me to do more work or better work. I do more, give more, and engage more deeply when my interests and ambitions are connected to those of the organization.

Neither the carrot nor the stick get me to do more work or better work.

In the August '05 issue of PMI's PM Network Neil Whitten offers his advice on getting more from our teams. He wants project managers to "Celebrate" the accomplishments of the team. "Leadership," he says, "means acknowledging a job well-done by thanking the project team that did it." Neil urges readers to do this at least once every three months. The Gallup Organization's research supports that as published in First, Break All the Rules, by Marcus Buckingham and Curt Coffman. Except, the research showed that people in continuously high performing organizations receive acts of appreciation and acknowledgement at least once every 7 days! Read the rest of this entry ¶

A very interesting project has begun to develop trustworthiness in open systems software. It goes by the name of TROSTing. The project investigations are quite ambitious:

• How can we be reliable at delivering open-systems components with demonstrable trustworthiness?
• After that, how do we continuously strive for achieving and sustaining new levels of trustworthiness?

While I wonder what will come of such an ambitious project, I can't help but marvel at the thoughtfulness that has gone into the creation of the symbol of trust.

The symbol is a keeper. The important work remains.

Dennis Hamilton, the designer, calls the symbol "a fusion" of the Shewhart/Deming Cycle of Learning, Fernando Flores' Action Workflow, partnership, and an ever-progression (spiral) of one interaction to another.

I met Dennis when my auto-responder for the Let's Play Catch! mini-course failed to deliver one of the lessons. He wrote asking for the missing lesson. One thing led to another, soon we were deep into exploring what each other was doing. Dennis is in the midst of finishing his thesis for a masters degree in IT. He is also writing a weblog on open systems along with starting to build a community to explore trustworthiness in software.

I can't help but think of the application of a mark of trustworthiness for the project environment. Can you imagine the equivalent of the Good Housekeeping Seal of Approval on a company offering to do project work? What could that mean? The AEC industry can be so contentious and generally distrusting. What if there were a collection of firms that were known broadly for just the opposite behaviors? There's no telling what might be produced by a consortium of those firms.

It's easier to talk about trust than it is to be trustworthy. I commend Dennis for putting this issue in front of us. Let's join him in his pursuit.

The May 1, 2005 Industry Week editorial Wanted: Inspired Leaders, Engaged Employees, by editor-in chief Patricia Panchak, calls attention to the poor job manager-leaders are doing bringing the good and bad news to our organizations.

We must find a way to deliver this news — the good and the bad — in a way that inspires employees.

Ms. Panchak cites the low level of unemployment and reveals those unemployed are taking longer to find new jobs. She goes on to say job satisfaction continues to fall citing these recent findings:
The Conference Board Reports, Many Are Simply 'Showing Up For A Paycheck'.

• 40% of workers feel disconnected from their employers.
• Two out of every three workers do not identify with or feel motivated to drive their employer's business goals and objectives.
• 25% of employees are just "showing up to collect a paycheck."

Ms. Panchak says we can't provide leadership without looking at the above list from the employees' perspective: "problems of persistent unemployment, flagging job growth and general economic uncertainty."

We live in challenging times. The times are challenging for our company. The times are challenging on our projects. We know from our own experience that we don't want our leaders to be motivating us. We need something different. Speaking only for myself, I want to be inspired by the work I do, the people I work with, and the opportunities that come my way. While I won't leave that solely up to someone else — I recognize that I have a big role in inspiring myself — I want to be around leaders that inspire me.

It's that time of year again. Baseball is on our minds. Only this year the NY Yankees are in the basement. Perhaps they need a little of Lou Pinealla's wisdom. My friend and co-blogger Joe Ely (also a baseball enthusiast) writes Learning about Lean. His latest posting Making Change Happen references the work of Jeff Angus.

Jeff has a marvelous weblog Management by Baseball where he offers an interpretation of management and leadership inspired by his years writing about baseball and consulting to business. Last week he offered this posting on leading change in organizations, Slipstream the Cosmic Wisdom of Lou Piniella. Jeff's wisdom comes through even for those of us who are not wrapped up in the game. Here's Jeff's wrap-up of the Lou Piniella approach to change:

BEYOND BASEBALL
The Piniella Solution then, is

• Start at the bottom of the org chart and solicit suggestions in the "What needs changing/improving around here" line.
• Act quickly and publicize the change.
• Follow up with more right away so you can accustom staff and adjacent departments that change is an on-going thing, and that it has payoffs.

The approach is not effortless or without its own potential pitfalls. Many times, line workers "don't get it", "it" being strategy or marketing fine points or subtle initiatives. Some suggestions will be entirely dysfunctional and not based in any reality. Okay, both are frequently true, but line staff know things others don't, those things are usually not valued, and there's much more to be mined there.

Taiichi Ohno had similar advice: Go to the workplace. I wonder what else baseball and Toyota have in common?

A number of project managers have asked me, "What does it take to be a leader on my project?" One of the best formulations of leadership that I've found comes from an unusual source — a rabbi, a psychologist, and author:

"Leadership can be thought of as a capacity to define oneself to others in a way that clarifies and expands a vision of the future."

Edwin H. Friedman, Friedman's Fables

What is the practical application of Friedman's leadership description? Start with the questions,

"What is the possibility that I am committed to?"

Are you committed to a collaborative project approach? Speak about it.
Are you committed to the possibility of completing your project early? Tell everyone.
Do you see that the team can accomplish more than what they've promised? Encourage them.

Leaders speak about what they see as possible. And they do so in a way that engages others in that possibility. Speak. Take a stand. Lead with your passion and invite your team to do the same.

The Project Reformer's e-Tip of the Week

041: Be Patient, Rather than Press for Drastic Change

Shorten the project schedule. Eliminate the delays on the project. Get people working in all available areas. Do it right the first time. Cut the budget! Does any of this sound familiar? It should, we hear it all the time on projects. But just calling for change doesn't work. Projects and project teams require care and attention, and on top of that change takes time. People do what they do because they've been doing it for quite some time. The more we repeat our actions the more we limit our view of what is possible. You want to implement the Last Planner System®? Good luck! People have been trained to rely on a WBS, the CPM, and calculations of float to manage their projects. You can't replace what they know with what they don't know. They won't let you. Succeeding with organization change takes persistence and patience, with an emphasis on patience. Being patient is not passive. Stay actively engaged with those people who must change. Encourage them. Acknowledge them. Appreciate their efforts. And…stay with them so you don't miss their moment(s) of breakthrough. Inspired by Taiichi Ohno as recounted by Jeffrey K. Liker in The Toyota Way, p. 98. The Project Leaders' Studio The Last Planner System is a registered trademark of the Lean Construction Institute.

©2005 Hal Macomber | RPM | e-Tip Archive | PDFs | Submit Tip

What tips do you have for running projects more successfully?

Bart Bolton offers Smart Advice in Information Week on succeeding as a manager, 10 Tips for Becoming a Successful Manager.

The emphasis has to be on leadership and interpersonal skills.

Bart starts with leadership and ends with producing results. That seems about right. He offers a good list. I've added resource for each of his tips.

1. Leadership
   The Leadership Challenge, Jim Kouzes and Barry Posner, one of the best of over 22,151 leadership books on the shelves at Amazon
2. Relationship building
   Building Trust: In Business, Politics, Relationships, and Life, Robert Solomon and Fernando Flores, no better book on relationship-building
3. Learning
   Mastery, George Leonard, when mere competence is not enough
4. Business acumen
   What the CEO Wants You to Know, Ram Charan
5. International cultures
   I lived and worked in Europe for two years working with divisions in 22 countries. I have no idea what to recommend. Anyone have insight? Please leave a comment.
6. Listening
   Developing the Master Skill of the Leader, Hal Macomber
7. Mentoring
   Equipping 101, by John C. Maxwell
8. Project management
   Ten Rules for Project Managers, Hal Macomber
9. Change management
   Five Necessary Actions for Change (Special Report), Hal Macomber and Gregory Howell, a practical introduction
10. Producing results
    Execution: The Discipline of Getting Things Done, by Larry Bossidy, Ram Charan, Charles Burck

Of course we can't go to work on all ten areas at once. I suggest you start with something you are already good at. Build on that competence. Then, pick another area of competence. Do this a few times before moving on to a more challenging skill area.

Software plans often lack common sense (and a) user focus

eWeek reports the FBI is likely to scrap their $170 million Virtual Case File software project. It's not the first big software project to fail, nor will it be the last. What I find interesting is the explantation offered by Eric Lundquist, editor-in-chief of eWeek, in the January 31, 2005 issue. Lundquist speculates (he says he doesn't have first-hand details) it is the compound effects of "too much turnover at the top management levels, too many promises of what the software would be capable of doing, and too little contact with the people who would use the software of a day-to-day basis. He sums it up as, "Software plans often lack common sense (and a) user focus.

We need a new common sense for developing and delivering projects of all types. I'll echo Lundquists speculations and I'll add a few of my own. Projects run well when the planning and execution are tightly coupled in a way that adapts to what the team is learning, innovating, and encountering. Call it agile or call it lean; either way, put the people performing on the project at the center of your concern when managing it.

Previous in series Next in series

Develop yourself as a leader in Walla Walla:

"We designed BeyondLeadership to help individuals discover how to teach themselves what they need to become the leader they aspire to be. Rather than learning to follow others' models of leadership, participants investigate their own behavior patterns. By discovering how they succeed and fail in their own situations, they begin to learn the lessons that grow into the ability to more consciously employ their skills, especially in those moments when different choices are needed."

Join David Schmaltz and Amy Schwab at their residential leadership development program for project leaders. These two people will push you, nurture you, and keep you just at the edge of discomfort…just the place you need to be for a great learning experience. Check it out!

By now you might be agreeing with Patrick Lencioni's book title, Death by Meeting! Hold on…the protocols all work together.

We have a process for making ready the requested work so it can be promised. We have a process for making promises day-by-day for performing the work. Now we need a process for finding out what work is in process and what is being completed. We can't wait 'til a weekly meeting. Why? Because your work tomorrow depends on my completion today. Coming into work tomorrow only to find out that my group hasn't finished now creates a mess for you and your workgroup. If you could have found out two days earlier you would have adjusted your workplan.

The daily coordination meeting is a very short meeting. You'll want to conduct the meeting standing up. And if you have to conduct the meeting on the phone, then get everyone to promise to be standing when they are on the call! No kidding. Getting comfortable will only extend the meeting. Also, no coffee, doughnuts, birthday cakes, etc. This is a meeting to fine tune the work we are doing with each other. It doesn't take more than 15 minutes.

The meeting starts by asking people to report complete on the work promised for the day. "I'm done" or "I'm not done" are the only allowed responses. Only complete work releases work for other people. When someone reports "Not done" ask for a new promise. You'll also want to ask what kept the performer from completing as promised. Record the reason provided for future analysis and removal of the cause of the planning (promising) failure. Record the number of promises completed as a percent of promises made for that day. Graph the results and display the graph where you conduct your daily meeting. Record the reasons for plan failure in Pareto chart fashion (vertical bar chart by reason type). (Make a Pareto chart quickly.)

Next you'll want to ask people if they need any help to complete their promised work. Often constraints will arise in the course of doing the work in spite of the effort given to look-ahead planning. This is also a time for people to announce that they will be doing work identified as workable backlog.

What's the best time to have a daily coordination meeting? It depends: either at the beginning or end of the workday. On construction sites the end of the day works well. It gives people the opportunity to do some replanning overnight and to authorize some overtime to complete work before the start of the next day. In other settings — new products development, software, engineering, architecture — the beginning of the days seems to work well. People are often keeping different work hours. The beginning of the day schedule allows them to fine tune their actions for the day.

Are we complete? Not yet. Last up, improving the system performance.

Previous in series Next in series

The Weekly Work Planning session is the time when performers make promises for the completion of work in front of the other project performers. This public promising is essential to producing reliable workflow. Try a thinking exercise with me to see the advantage of the approach.

Let's say you and I and another four people have working groups of people that we lead on a project together. Each of us manages a team with a different specialty. So we start our weekly work planning conversation by reviewing the promises we are making for completing work day-by-day in the coming week. I start by saying my group will have tasks A and B done on Monday, tasks C on Wed, and tasks D, E, and F on Friday. Independent of me you have planned your group's work. You have your own tasks, but your team needs to coordinate with my group. You might need access to the same physical space or controlled documents. So you ask me, "Hal will your group really be done with task B on Monday?" I say, "Sure will. We're mostly done already." "Great!" you add. "I'll then move up my task G to start on Tuesday and finish on Wednesday."

If we had individually negotiated those workplans with the project manager you would not likely have found out you could get started early in the week. Further, others on the team may now plan their work based on both the promises I made and the revised promises you made.

Performers (last planners) prepare their workplans outside the meeting. Each group submits the WWP to the project manager prior to the meeting so that the plans can be compiled into a single plan organized by workstream.

Start the weekly work planning meeting with a review of the prior week's performance. Go through the PPC (percent of promises/plan complete) for the overall project and the individual workgroups. Add the data to a graph if you haven't done so already. Have a short conversation about what you might expect in the coming week.

Next, review the Pareto data for the reasons for not completing work as promised. Look for patterns in the data from one week to the next. Examine the data by performer group, as well.

Now, have a conversation about the coming week's work by workstream not by performer. You want to give attention to how one group's promises connect to other groups' performance. This is critical to establishing a base for reliability. When one performer sees how their promises impact others, then the reliability of promising will improve. Make any necessary adjustments to individual plans so that work flows smoothly from one performer to another. Add time buffers between performers when you can expect unreliability of completion (either low performer PPC or anticipated variability in the project).

Review the workable backlog that has been planned for the coming week. Give people the opportunity to negotiate workable backlog away; for instance, I might plan to do a task that would put the project out of sequence for you. You should have the opportunity to ask me not to plan that work.

Finish the meeting with a Plus-Delta (+Δ) review.

By now you've got to be thinking, "No project work happens that reliably." That's right. Research conducted by the Lean Construction Institute showed that usual teams working from schedules are about 50% reliable completing what they set out to do sometime in the coming week. That is insufficient for coupling one workgroup's tasks to another's. However, people using these protocols are routinely getting reliability of 85% to the day promised. That is sufficient to couple work among performers and workgroups.

There's still a missing piece. The secret is in reporting complete on the work performed. For that we'll take a look at daily coordination meetings.

Previous in series Next in series

Last week I proposed a set of meeting protocols for conducting projects on a lean basis. These protocols are used with the Last Planner System®. The first protocol is for the Look-Ahead Planning (LAP) meeting.

The point of the LAP meeting is to establish a plan that can be accomplished that closely matches what should be accomplished to meet the overall objectives of the project. I think of this meeting as the occasion for crafting or preparing the set of requests that will be made of the performers in the coming weeks. It is a meeting that the would-be performers attend. Those would-be performers look for the conditions of each up-coming task that would keep them from making a reliable promise at the time that a promise is needed. The lean project community calls those conditions constraints.

There are four objectives for the LAP meeting:

1. Establish the basis for weekly work planning — promising — in the coming week including identifying workable backlog.
2. To surface constraints.
3. To secure and manage the promises for removal of constraints.
4. To introduce the performers to the coming work.

A usual look-ahead plan has a six-week horizon. The meeting starts with a review of the coming week. Care is given to assess any remaining conditions (constraints) that would keep someone from making a reliable promise on the coming week's workplan. The project manager reviews any remaining constraints, the promises for removal, and then with the performers authorizes a set of requests for the coming week.

Next up is looking at week two on the LAP to see what work can be made available as workable backlog. The group evaluates what unconstrained work could be performed early if either a performer gets ahead or if there is some reason that would prevent the performer from doing the work as promised. The planning conversation ends by authorizing some subset of the second week's work as workable backlog. The group understands only the work authorized in the group conversation is to be workable backlog. This keeps people from doing work that could be out of sequence that would cause difficulty or rework for themselves or others.

The conversation then moves to a review of weeks three through five. There are two keys in this part of the meeting. The first is to review the completion of the promises for removing constraints. The second is to surface more constraints. The process of reviewing the coming work for six weeks has the effect of sharpening the group's attention. Invariably, no sooner has the group removed all the known constraints for a set of tasks than someone comes up with more constraints. During this conversation people are asked to make clear promises including completion dates for removing the constraints. People report complete on previous promises. The project manager updates the plan marking those tasks with no constraints "Ready for Promising".

Finally, the new sixth week of the plan is introduced to the group. For many of the performers they will be quite familiar with the new details because they were involved in establishing those plan details. The project manager highlights interactions of performers in the new work and asks them to identify constraints.

The meeting ends with a Plus-Delta (+Δ) — what produced value? and what might produce more value?

Depending on the complexity of the project and size of the project team these meetings can range anywhere from 30 minutes to 90 minutes.

Next up: the weekly work planning meeting…

Previous in series Next in series

Meetings, meetings, meetings…we have far too many that don't produce the value for the attendees or the project. Patrick Lencioni's latest book, Death by Meeting, makes the case for different meeting approaches depending on the purpose pursued. For more than 8 years the founders of the Lean Construction Institute have advised people doing projects on a lean basis to have special-purpose weekly project meetings. Over the next week or so I will offer my proposals for protocols for conducting a series of meetings that address a coherent set of project concerns.

I have identified four five protocols that are consistent with the Last Planner System®. These five represent distinct phases of the workflow of project work. Read the rest of this entry ¶

Next in series

Your own power and authority will only get you so far. You'll gain power when you share it. So goes the argument of the editor of Harvard Business Review. Read on…

The Project Reformer's e-Tip of the Week

036: Exercise Power Collaboratively

One of my favorite business writers is Thomas A. Stewart. Stewart wrote for Fortune Magazine and Business 2.0 before joining Harvard Business Review as editor. He's not doing much writing anymore. However, he does write the opening essay for each issue of HBR. I open to it each issue. The October lead article is titled "Surprises for New CEOs," a collaboration of Michael Porter, Jay Lorsch, and Nitin Nohria. Their article is a winner. Stewart's commentary is unforgettable. Stewart sums up the article with the following: "The more power you have, the more important it is to exercise that power collaboratively." HBR's target readers are the leaders of our companies. Stewart's one sentence conclusion is good advice for all of us who find we are accumulating power and authority. This is especially appropriate for project managers on big, or complex, or troubled projects. It's also practical advice. Project leaders can't be in all places at once. Projects by nature are distributed in their organization and execution. Sharing power with project performers only accumulates more power for the leader. The organization functions better when each member is in the position to act with authority. Try it. Explore with your team how you can share power with them. The Project Leaders' Studio™

©2004 Hal Macomber | weblog.halmacomber.com | e-Tip Archive | PDF | Submit Tip

Try this on your projects. First, discuss it openly with your project team. How collaborative are you in your leadership? You'll never know if you don't ask!

It takes an uncommon common sense to see opportunity where others continue to take the same old actions. Henry Mintzberg may be just one of those people. Most people know him from his provocative writing in the Harvard Business Review. A few have the pleasure of engaging with him as Professor Mintzberg, at McGill University, Montreal. In Professor Mintzberg's latest opinion piece he argues for less leadership, Enough Leadership, HBR, November 2004. But read it closely; what he really is calling for is more leadership from people throughout the organization.

The professor asks three questions:

• If leadership is about stimulating teamwork, how are the stock options distributed in your company?
• If leadership is about taking the long view, how many of these stock options can be cashed in in the short run?
• If leadership is about building trust, if people are really a company's "greatest assets," how many of these assets have been shown the door in recent years? And how much trust has that engendered among those who remain?

Provide just enough leadership to support the efforts of others.

We know too well the answers to these questions. And we see the business results that go with those answers. The common sense in the business world places too much responsibility on a few people for the well-being of the firm, the employees, shareholders, and customers.

The professor uses an example from the IBM company turnaround to make his point. Lou Gertsner is often credited in the press with riding in on a white horse to save IBM. In the example of IBM's entry into the world of e-business, Professor Mintzberg argues:

"Instead of setting direction, (Lou Gerstner) supported the direction setting of others. He provided less leadership, but appropriate leadership. Just enough leadership."

The professor prescribes three actions for providing just enough leadership.

1. Stop the dysfunctional separation of leadership from management.
2. Involve the followers in the selection of the leaders.
3. Recognize the importance of (leaders) being engaged.

In closing, Professor Mintzberg characterizes the situation with lines from a play,

"Unhappy the land that has no heroes."

"No," says another. "Unhappy the land that needs heroes."

The parallels to our situation on projects couldn't be clearer. So often I hear people say that what we need is a change or injection of new leadership. Rarely does one person make that significant difference. What we need on projects is to cultivate leadership throughout the project team.