How to Grow Communities of Practice

February 26, 2010 — Bruce McGraw

Change is a constant in a project manager’s world (well really in everyone’s world!). People who fail to learn—to increase their understanding and skills—find adapting to changing conditions and requirements challenging, if not impossible.  Just as individuals need constantly to learn, so do organizations. One of the most effective ways for organizations to learn is to collect bits of individual learning into corporate knowledge that can be shared—we used to call this knowledge management.

An early proponent of organizational learning was Peter Senge, an MIT professor and author of The Fifth Discipline.  Senge tells us that a Learning Organization is one "in which you cannot notlearn because learning is so insinuated into the fabric of life." He concludes: "The rate at which organizations learn may become the only sustainable source of competitive advantage."

Although formal classes abound in many organizations, an effective learning facilitator that is less in evidence, are communities of practice. A Community of practice (CoP), according to cognitive anthropologists Jean Lave and Etienne Wenger, are “groups of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly.”  CoP’s operate across the organization bridging established boundaries in order to increase collective—or corporate—knowledge, skills, and build professional trust. Communities of practice enable sharing ideas, lessons learned, and tricks of the trade. (Remember I work for Cognitive Technologies which has a bunch of cognitive knowledge engineers who are always telling me about this cool stuff)

Writing for Harvard Business Review in 2002, Wenger and colleagues Richard McDermott and William Snyder offer 7 principles for successfully initiating a CoP within an organization. 

  1. Design for evolution—limit rigid rules and structure for the group; expect it to change over time
  2. Open a dialogue between inside and outside perspectives—it is amazing what can be learned from people with a different background or set of experiences
  3. Invite different levels of participation—some members may participate actively while others learn quietly through reflection and emersion
  4. Develop both public and private community spaces
  5. Focus on value
  6. Combine familiarity and excitement—regular meetings, web site use, email exchanges are familiar. However, excitement can be generated from inviting folks who challenge business-as-usual ways of thinking or offer ideas on potential projects or discussion areas.
  7. Create a rhythm for the community—this is the ebb and flow of events and interactions, the frequency of formal and informal get-togethers. Sometimes this will be quite active, almost breathless and others will meander like a quiet stream.

In implementing CoP and in working with others who have, here are a few tips I learned about ways to ensure that a CoP is useful, effective and enduring.

  • Communities of practice do best with internal leadership and initiative.
  • Sponsors and community leaders must foster the community’s development among practitioners.  (I am talking about all you senior PMs in the project community)
  • Create structures that provide support and sponsorship for these communities and find ways to involve them in the conduct of the business without thwarting desirable open sharing among participants.
  • Develop trust relationships in the beginning through face-to-face interactions among participants.
  • Choose a person to coordinate the resources that will be shared and set up the meetings–this position probably should be rotated.
  • Identify the desired frequency of meetings (monthly? Quarterly?)—this helps build familiarity and rhythm.
  • Introduce virtual conferencing tools that can be used to facilitate group discussions—make sure participants know how to use them.  We use GoToMeeting here at Cognitive Technologies.
  • Create interesting and provocative discussions by building a prioritized list of the most pressing PM issues, most frequently asked question areas, or lessons learned around a single PM topic.

The Knowledge Garden offers further insight into Communities of Practice, Knowledge Ecology, Organizational Intelligence and Virtual Communities.  Some of you might not be PMs but rather business analysts, software developers, designers, etc.—you should create a CoP also.

Have you created a community or participated in one, please share your experiences, comments, and suggestions.

Posted in Collaboration, General Project Management, staff. Tags: , , . 2 Comments »

RESPECT – How NOT to be the Rodney Dangerfield of Project Management

February 18, 2010 — Bruce McGraw

Do you go around saying “I get no respect!”?  Project managers who say they are not getting respect usually mean that their comments, warnings, suggestions, and requests do not change the behavior of those they work with and for. Perhaps that is true. However, it is also possible that the power distribution scheme in your company is not setup to recognize or utilize the contributions of project management.  

Sixty or seventy years ago, when your parents or grandparents began working for corporations, the internal organization—and power structure—was setup around product groups and profit centers. Each group had a manager responsible for all activities and personnel necessary to get a product out the door and to make a profit. Product managers were respected.

Then in the 1980’s and early 1990’s, large corporations started merging into giant corporations. Lockheed, Martin, and Loral became one company; Boeing and McDonnell Douglas were married, Citi merged or acquired Traveler’s Insurance, Smith Barney, Salomon Brothers, The Associates and many more. To ensure that the mergers made financial sense, these mega-organizations looked for ways to cut costs. Within the product-oriented organizational structure, they found (OH NO!) duplication of functions. To the rescue came the “matrix organization” (You can read a description of this in chapter 2 of the 4th Edition PMI PMBok Guide).

In a matrix organization, groups are put together based on functions or skills. This organization style means that project managers are often in reality project facilitators with only informal control over personnel. They must rely upon the functional managers for project resources.

To receive respect in a matrix organization and to achieve the goals of your project, you need to utilize some of the same behaviors and attitudes discussed in previous posts such as Working with Support Organizations and The Accidental Project Manager Part 2. However, there is more to gaining respect than getting along. You must:

  1. Know where the power lies. Managers within the functional organizations wield the power to assign resources and establish priorities. To gain their respect takes research, insight into motivation, and time. One useful strategy is to figure out how to help them by offering advice and information they can use to do their jobs.
  2. Know your job and back up your requests and assertions with data. Give trust, but more important BE TRUSTWORTHY.
  3.  Keep your relationships “adult-to-adult” within the matrix. Adults negotiate; strive for consensus, resolve conflicts, and respect each other’s opinions according to Paula K. Martin, CEO of Martin Training Associates.
  4. Don’t play childish games. Here are a few games—interactions with ulterior motives—from Eric Berne’s classic transactional analysis book, Games People Play that you should avoid:
    • “Why don’t you…yes, but”
    • “Ain’t it awful”
    • “I’m only trying to help you”
    • “If it weren’t for you”
    • “Look what you’ve done to me”
  5. Ask for help. People, including the managers within a matrix organization, are more likely to respect the person who asks for their help in getting a job done than they are to respect someone who acts as if they have all the answers.  The trick to making this strategy work and increase the respect you receive is to be sincere.

    I am not suggesting you learn to fake sincerity. I am saying you really have to want to know how to get Group A to do what you need done for your project. If you have failed in the past to gain respect or support, start your discussion with an admission about the past, followed by the request to learn how to do it better.

  6. Be professional.  Even when you are being treated with no respect and others are playing games, you should be professional and respectful in your actions and attitude.  While this may not seem to work in the short term, it has huge long-term benefits. 

I am sure readers of Fear-No-Project would appreciate your experiences in successfully gaining respect for you and your project within a matrix organization. Please share via comments.

Posted in General Project Management, management. Tags: , , . 2 Comments »

Good Project Plan Schedules

February 12, 2010 — Bruce McGraw

I had a great conversation this week about one of my earlier posts on creating effective and predictive project schedules.  It appears this subject is one of the common topics used in the maturity models being utilized these days.  So I thought I would give another perspective on creating a good project schedule.

Project schedules are essential tools to manage a project effectively – and when constructed correctly they also provide a predictive view of that schedule. Creating a schedule requires the PM to breakdown tasks into manageable parts, establish relationships among tasks, ensure that deadlines can be met, and assign sufficient resources to tasks. Here are some guidelines about project plan schedules from authoritative project management sources.

According to the Project Management Institute (PMI) in the accepted Body of Knowledge for Project management (PMBOK)

Project plan development uses the outputs of the other planning processes, including strategic planning, to create a consistent, coherent document that can be used to guide both project execution and project control. This process is almost always iterated several times. (PMBOK 4.1.3, pg. 44)

The PMBOK further states:

The project plan is a document or collection of documents that should be expected to change over time as more information becomes available about the project. (IBID)


Also, according to the Software Engineering Institute’s (SEI) Capability Maturity Model® Integration (CMMI), Version 1.1, Project Management is a key part of the maturity process and has two key areas for project plans considered areas for achieving the higher levels of maturity: 

  • Project Planning – Goal 1: Establishing Estimates, Goal 2: Developing a project plan.
  • Project Monitoring and Control – Goal 1: Monitoring the Project against Plan

To create a Project Plan schedule that meets all of the standards of a mature project schedule, both as defined in the PMBOK, the CMMI v1.1, and as widely accepted by Professional, certified project managers, should contain at a minimum these 10 items:

  1. Sufficient level of detail (Work breakdown and task sizes)
  2. Defined resources (Named)
  3. A complete network of dependencies (Adequate hard logic)
  4. Specific assignments (Resources against tasks)
  5. Sufficient use of milestones (Includes all Deliverables)
  6. Plan baselines (A static copy of the “plan” against which measures can be taken)
  7. Few constraints on tasks (Constraints are fixed and not predictive – like “Must finish on”)
  8. Actual work being recorded in the plans ( Actual work done on a period by period basis)
  9. Accurate metrics being calculated (Earned Value)
  10. Integration of all project schedules to provide a dynamic forecast and predictive outcome of impacts (“Workplans” or tasks for each team which form the complete schedule)

SEI summarized the use of project plans as:
“A project’s documented plan is the basis for monitoring activities, communicating status, and taking corrective action. Progress is primarily determined by comparing actual work product and task attributes, effort, cost, and schedule to the plan at prescribed milestones or control levels within the project schedule or work breakdown structure. Appropriate visibility enables timely corrective action to be taken when performance deviates significantly from the plan. A deviation is significant if, when left unresolved, it precludes the project from meeting its objectives.”  (CMMI V1.1, pg 219)

One other bit of advice about schedules based on my observations and experience:

A dangerous time in the life of a project is in the middle of the schedule. After the excitement of beginning the project and before the end of project—everything has to be done by when?—there is the sometimes abandoned middle. In the middle of a complex project execution, it is easy to assume that “there is plenty of time left”. One forgets the logic and experience used to build the original schedule.  Remember that a project schedule is not a “wall chart” to be placed on the wall and admired!

Bad idea! Bad practice!

Project managers need the discipline to monitor schedule and plan compliance every week. During project execution, project schedules should be monitored by actual work recorded against the plan.  This means tracking time against tasks.  This allows metrics to be used in the project processes necessary on large projects.  Using staff estimates of percentage complete rather than actual work performed and estimates to complete, is not an accurate method of monitoring progress on a large, multi-project program.  Additionally, without documented, supportable statistics, managers have no credible evidence to support resource demands during the execution of the project.

Following these basic principles gives you a better than average chance that your project schedule is a useful, predictive schedule and not just a static wall chart.

Posted in Best Practice, management, schedule. Tags: , , . 2 Comments »

How project managers should work with support organizations

February 6, 2010 — Bruce McGraw

Inside the nether regions of large companies lurk individuals and offices that are part of executing a project but reside organizationally outside of the project’s chain of command. Placed within the somewhat amorphous group of support organizations are specialists in IT, travel, legal, facilities, HR and many more. A project manager rarely interacts with these individuals, but when their support is needed, there are ways to gain quick efficient help and methods that ensure your request is at the bottom of their to-do list.

Do your homework
If you are new to being a project manager or new to an organization, find out what support organizations are available and what their authority is. A few corporate documents that help are organization charts and the P&P (policy and procedure) or SOP (standard operating procedures) manuals. I know that reading the SOP manuals is no one’s idea of pleasure reading, but at least skim the titles in the table of contents to get an idea of what’s available.  And who knows— they may even be online for reference!

Look at the signatures required on routine forms like travel requests, conference room reservations, document releases, network access requests and presentations. Introduce yourself and your project to the people in those areas.

Before you have to work with the support organization to get something done that has a deadline, find out what information they need from you and their typical processing timeline. Build that into your project schedule.

If in doubt, check with a secretary or admin. You might have thought I was going to say, “see your supervisor or manager”. However, in my experience, the people who best understand how things get done are not higher in your management chain, but rather the office and administration staff.  They are the ones that have to “get it done.”

What to do
Put sufficient time into preparing support service requests and allow them time to respond. Remember the secretary’s motto:

“Your failure to adequately plan does not constitute an emergency for me.”

If possible, walk the papers or send the email yourself. I try to make sure that my dealings with support staff are good and friendly so that they remember me.  Make sure you provide everything the support service needs to do their job. After a reasonable amount of time (an hour or a day, depending), check back. Ask if they need any additional information. Offer to pick up the document or materials rather than wait for the inter-office delivery system. Use both opportunities to get to know the support personnel as people and not functions. In addition, let them get to know you.

When the task is completed—especially if the task was complicated or outside normal business operations—thank them personally for their work on behalf of your project. If the effort was particularly noteworthy, provide a more formal “thank you” to their manager (see organization chart) emphasizing how they helped meet broader organization goals. This not only makes them feel good and part of the team, it will establish a warmer reception for your next support request.  I have been known to drop off a box of doughnuts or candy after someone has really gone the extra mile to help me out.

If something goes wrong—late, incorrect, rejected—leave your ego at the door and try to understand. Offer to help, if possible, or learn from the experience. A Mind Tools article on “Conflict Resolution” suggests the best way to solve a conflict is to keep good relationships a top priority, separate people from problems, and explore options together.

What NOT to do

  • Act as if your project is the only one they have to support.
  • Be an anonymous voice demanding action—see “get to know the support service people”.
  • Try to bully them into cooperating. No matter how high on the org chart you may be or how important your project is to the organization, you do not want the support organizations as enemies.
  • Cop an attitude.
  • Fail to confirm the facts.

Support organizations can help you do your project management job or they can make your life miserable. The ball is in your court. Share your experiences and recommendations on working cooperatively with support organizations in your company via comments.

 

 

Posted in Collaboration, General Project Management. Tags: , , , . 3 Comments »
Follow

Get every new post delivered to your Inbox.

Join 354 other followers