Change management

Experienced project managers know that change is inevitable and there are many consequences of failing to manage project changes. Some of the critical consequences are;     

• Scope creep
• Cost and budget overruns
• Project delays
• Poor quality of the project deliverable
• Often the project team performs incomplete work for the project deliverables
• Stakeholders express concerns about the project manager’s ability to manage the project

So the problem is not the change itself but how the change is managed. There are many benefits of managing changes properly such as increased stakeholders’ satisfaction, improved quality of the project deliverables, opportunities for the additional project work etc. There are basically three types of changes that need to be addressed in order to ensure a project success. These are; 

Technical changes: These are the internal modifications in scope of the work of the project. 

Market changes: These are changes that are inevitable due to external market conditions such as competitors’ product or service enhancements or regulatory changes. 

Contractual changes: Changes that are made on the contract with the stakeholder or supplier. These changes include but not limited to the terms & conditions, scope of work, requirements, schedule, costs etc. 

The most important function of a project manager is to prevent uncontrollable changes. Uncontrolled and unexpected changes in user /stakeholder expectations and requirements as a project progress always negatively impact a project. This is known as scope creep. Many times new features are added to the project with a wrong assumption that one small feature will add nothing to cost or schedule. This unplanned addition is called feature creep. 

A change in the one of the  triple constraints of a project has an impact on the other two. The key is to find balance between the need to manage the scope of the project against the agreed requirements, cost & schedule. 

Impact Analysis for Change Request

Changes may negatively or positively impact a project. When a change request is made, you as a project manager need to analyze the same in order to evaluate whether it is within or outside the scope of the original project requirements as well as how it is going to impact the three constraints of your project namely scope, schedule and cost.  Impact analysis is the most important step to effective change management procedure.  Your impact analysis should not only reveal the impacts of changes on the above three project constrains but also it should provide you the essential information related to the effects of changes on people, processes, quality of the project and on the operation of your company.  By implementing proper impact analysis procedure you should also be able to evaluate the overall project risks, how the change is going to alter the existing risks, whether or not the project is going to face new risks and the cost associated in managing those risks.    

Every organization has its own way of doing things and in most cases structured processes are available.  You need these organization process assets that may or may not have formal procedure for impact analysis. However, the following guidelines will always help you understand essentials of impact analysis procedure and how you can diligently implement such procedure. 

Step one: Do you have the money? 

Every work involves some cost and the impact analysis of change requests also requires some budget especially when it is a large change request.  Do you have the contingency budget to cover the cost or do you need to request the project sponsor / customer to pay for the added cost? 

Discuss this with the project sponsor and always come up with adequate numbers so that you can properly make formal presentation to the project sponsor and request the extra fund that you need for the impact analysis. 

Step two: Determine the reason for the change. 

Why the change request is made in the first place? Can you avoid it / defer it or is it inevitable? Determine the business need for this change and how the change is going to benefit the project, the process, the work product, the quality, the stakeholders and the organization.  Also review the Change Log to determine if the amount of change is excessive on the project. If change is certain, determine what is the priority of this change in comparison to other changes, such as current requests and requests being implemented? 

Step three: Analyze the impact on triple constraints. 

Scope: Determine the impact on the overall scope of the project, Work Breakdown structure (WBS), Product Breakdown Structure (PBS) and Resource Breakdown structure (RBS). You need to find out information in details by identifying the product features that would need to be added, changed, or deleted and any sections of the PBS, components of the WBS that would also need to be added, changed, or deleted and also the resources that would be required to implement changes and how it is going to alter the RBS. 

Also you need to identify any changes that need to be made to the agreement with the customer or any vendor or subcontractor.  

Cost: Identify any changes that need to be made to the cost management plan and the overall financial plan. Who is going to pay for the added cost? Find out whether the change will be paid for by an external sponsor. Similarly like scope, you also need to identify any changes that need to be made to the agreement with the customer or any vendor or subcontractor.  If subcontractors are involved, determine whether the change is going to impact the subcontracting cost. Refer to your organizational process assets and guidelines to ask for the additional cost or price for the change from the procurement department. Your impact analysis report also should highlight the financial benefit to the project and the financial benefit to your organization. You should also document other benefits such as improved schedule, better performance, lower risk, future opportunities, stakeholder satisfaction, enhancements to the organization’s intellectual capital, and technological advancement. 

Schedule: Your project needs to be completed within time otherwise you are invariably going to incur cost overruns because the project schedule is linked to scope and cost. Estimate the time required to define and plan the proposed solution and the time required to implement the proposed changes. Evaluate the changes to the milestones and to the critical path.  Also identify the changes that would need to be made to the Work Breakdown Structure (WBS), the project management schedules and the milestone lists. Determine changes to the contractual schedule with the subcontractors. Also determine the impact of the change outside the delivery organization by identifying any changes that would need to be made to the Agreement with the sponsor and with any subcontractors. 

Step four: Identify dependencies 

Your various project activities are interwoven by complex successor relationships.  Identify other tasks that are dependent on this change being approved. Also determine the predecessor relationship and prioritize the tasks that must be completed before this change is implemented. Also it is equally important to determine the resource dependencies and how you are going to use resources for this change.  And finally, you also need to identify other dependencies such as market conditions, government regulations etc. 

Step five: Analyze the risks 

Analyze the risks that are associated with this change. Identify all the risks qualitatively and quantitatively the project is facing or will face in the future due to this change. Also identify threats that are associated with this change. Threats would include changes that have possible negative impacts or risk. Even a small change might include a high amount of risk. 

Step six:  Determine the impact on the Project management system 

Identify and list all the changes that would need to be made to the project procedures description or to the project decision structure. Identify changes that would need to be made to the communications management plan, the project quality plan, the risk management plan, the technical environment plan and overall the project management plan.  Also determine the costs to update the project management system.  

Step seven: Document your findings  

Properly document all the results of your impact analysis. Prepare a detail report for the change control board to approve changes. Follow your organizational process assets and procedural guidelines to document reports of the impact analysis. When the change request is approved by the change control board, the change order is created. Identify the project documentation, including the project management system documents, which must be changed or updated to reflect the approved change. Update the financial management plan when a change has a financial impact. In order to show the changes to work items or completion dates, update the project management schedule, operational schedule, and the work breakdown structure. Most of the change request is associated with changes to the scope and in such scenario update the project definition, deliverable definition, or other documents that control the project scope.  Also update the technical specifications, the test plans, the quality management plans.  A great deal of a project manger’s time is spent on communication.  With every approved change request, you need to prepare new reports or arrange new meetings and that is why it is imperative that you also update the communications management plan.  Most important document update is the updates on the risk register. Document all the qualitative and quantitative risks and also include updated risk definitions due to this change.  

If the change control board approves a change request then you need to create change management work product that will consist of change request templates, instructions for the changes or the change order and a log to record changes.  

Implementation of change management also equally important and things may go wrong if a project manager fails to properly implement change management. That is why it is important that the project manager work cohesively with the team as well as with the change control board.  

Also another important factor to remember is that the impact analysis for multiple change requests may not reveal hidden costs. In such scenario, it is always recommended to rely on expert judgment.  

Identify stakeholders and bring them early. Stakeholders who are found later will make changes and could cause delays. Any change that is made later is harder to integrate and is much more costly. Communicate with the stakeholders effectively and on a regular basis. Give a project presentation, list all their issues and concerns, report progress and inform changes and updates to the project management plan. Another important function of a project manager is to prevent uncontrollable changes. Stakeholders have greater influences over the requirements as well as changes in a project. That is why it important to have effective communications within the team and between the team and other project stakeholders.

Let’s try to understand why do you need a communication management plan?

• Communications management plan reduces and mitigates risk
• It provides you clear guidelines on how  you formally  interact with the project stakeholders
• Communication management  plan provides tools to utilize resources effectively
• It gives you the ability to analyze the impacts of various meetings
• It also ensures mutual commitments with the sponsor and other stakeholders
• The Communications management plan clearly documents all the deliverables and delivery schedules
• You should  be able to deliver  the right message at the right time to sponsors so that you can control  rumors and unnecessary work products
• A well defined communication management plan enhances your ability to meet stakeholders’ expectations

A project manager inspires people, shares the project vision with the group and creates a very motivating environment.  Communicate with all levels of the members of your team regardless of level. Communicate clearly your plans & ideas and make sure everybody understands them.

Your communication management plan should include both internal communications and external communications. Your internal communication management plan includes status report, progress report, trend report, forecasting report, variance report, earned value report etc. External communications requirements include types of meetings and reports, existing policies and contractual agreements etc.

Here are some simple steps to create an effective communication management plan.

Step 1: Documents the followings

1. With whom you need to communicate?
2. What deliverables are needed?
3. What media you are going to employ in the communication?
4. When the communication will occur?
5. Where the communication will occur?
6. The purpose of the communication

Step 2:  Document the list of deliverables, the list of stakeholders and your stakeholder analysis for each stakeholder. You need to document communications requirements with the sponsor, with the functional management, the subcontractors and with the team.

Step 3:  Determine the needs for media. Your communication management plan should have a media section where you document the types of media that you plan to use for communications on this project. Document the media requirements to make sure that all stakeholders have access to the particular media or technology that they need for their required communications.

Most cases you will be using the following media types:

• Conference calls
• Fax
• Knowledge repositories available on company’s intranet
• Paper reports
• Power point presentations
• E-mails
• Video conferences
• Instant messages such as AIM
• Electronic files, including zipped files, word processing files, and spreadsheets
• Web sites
• Information stored electronically on company servers
• Project management software such as MS Project
• On line project tracking tools

Step 4:  Document a schedule for the milestones and communication deliverables. You should have a table or calendar that shows your deliverables and other communications time.

Step 5: Determine the assumptions, dependencies, and risks associated with your project communications.

List all important assumptions you considered while creating communications management plan such as all stakeholders speak English or all team members will be company’s full time employees only. This may change the moment you hire contractors.

List all important factors upon which your communications management plan depends. For example, the communication among team members located in several time zones depends on how and when they communicate, what communication media they use and how they distribute reports.  A dependency is an input or output or time-related relationship.

When managing dependencies, confirm that the deliverables are well-defined, within the project scope, and also include a statement of work. Confirm that the schedule and cost are understood by the parties involved.

Identify past, present and potential risks that the current project faced, is currently facing or will face in the near future and list any important risks inherent in the communications management plan.  

Step 6:  Every work involves some cost and in your communication management you should itemize the costs associated with communications. For example, you should have a list of cost associated with conference calls , video conferences, instant messages such as AIM, your and team members time in preparing reports, cost of using other facilities etc.

Step 7:  The final step is to review your plan before you finalize it. Here is a check list of your communication management plan.

• List of your stakeholders and your detail plan on their communication needs
• Organizational type such as projectized, functional or matrix
• Document any geographic or multicultural requirements
• If you are working with a remote team make sure remote team requirements are met
• Document use of technology against your stakeholders’ access and technical skills
• Check to be sure your stakeholders are assigned appropriately to the reports, meetings, and other communications types according to role, level of detail, and personal communication preferences
• Review all the levels of communication and do not overburden stakeholders with too much or too little information

Your communication plan also should include the communication methods such as formal, informal, verbal and written. You communicate internally and externally to the project team and vertically and horizontally within the company. Use the following guidelines for selecting a communication method. However, please remember that every organization is different and you need to take into account your company’s processes and procedures for conducting work and communications.

Formal written:  Project charter, reports to the management, project management plans, communicating between divisions etc.

Formal verbal: Presentations and speeches

Informal written: Notes, e-mails, memos, status updates among team members, online chat etc.

Informal verbal: Conversations, meetings, discussion and often water cooler gossip  

In step 3, we will discuss about project changes and  how you manage a change.

You have been a successful techie for several years. You have been working as a team leader at your current job for past eighteen months and you have just successfully completed a huge in-house software development project. Your project manager just got transferred to PMO with a promotion and you are the natural choice of your company to fill that vacant slot.  The company sends you for in-house project management training so that you understand the company’s processes and follow the guidelines of the PMO.  You are excited but bit nervous about your new role. You have acquired the theoretical knowledge about project management methodology and the company’s processes from the training you just completed but you do not know how to effectively implement them in your project.  At this stage anybody would be nervous as wise men said, “you do not know what you do not know”.

Relax! Here are the strategies to function effectively as a project manager and if you follow my simple albeit effective guidelines, you will be very successful in your new role as a project manager.

Step 1:  Understand top ten reasons of a project failure and proactively plan to avoid them.

Step 2:  A project manager spends over 80% of the time communicating. Have a solid communication plan not just a strategy.

Step 3:  Change is inevitable in a project. The problem is not the change itself but how you manage a change. Learn how to manage changes.

Let’s start with step one: Top ten reasons of a project failure.

1. Poor planning: Planning is the most important step of project management process. Half of the battle is won when you plan well. Coordinate with the project participants and the stakeholders to develop a detailed plan for the assigned project. Involve your project team members in planning and have the team buy-in. Prepare project scope, statements of work, work breakdown structures, task estimates, and specific tasks and milestones. Plan resources and schedule for your project implementation. Proactively plan effectively all anticipated bottlenecks, which include but not limited to management escalation, project prioritization, finding the right trade-offs between the business needs versus technical as well as triple constraints namely; scope, cost and schedule.

 2. Unclear goals and objectives: Many IT projects are elaborated progressively and in these scenarios you as a project manager need to rely on rolling wave planning. Initially the goal of your project may be only partially clear due to a poor requirement gathering in the definition stage of the project and you may not have clear picture of the scope and the schedule.  Defining clear requirements for a project can take time and lots of communication. You need to have expertise in rolling wave planning and that is where you should proactively focus.  You have strengths as well as weakness in this area. Being a technical team leader you can clearly view where the project is heading and you can very well anticipate the technical requirements and the future enhancements but at the same time you do not know how to plan for something that may be the future requirements. The best thing to do in such scenario is to rely on expert judgment.  Find project managers within your organization who have experience in rolling wave planning and seek their guidance. Your strategy should be to combine your technical expertise with experts’ judgments so that you can plan for your project that going to be progressively elaborated.

3. Poor Stakeholder Management: Identify stakeholders and bring them early. Project stakeholders’ interests may be positively or negatively impacted by the project and that is why stakeholders’ influence on the project is the most important thing to consider. Stakeholders who are found later will make changes and could cause delays. Any change that is made later is harder to integrate and is much more costly.

4. Scope creep and Feature creep due to objectives changing during the project: Scope creep refers to uncontrolled and unexpected changes in user expectations and requirements as a project progress, while feature creep refers to uncontrolled addition of features to a system with a wrong assumption that one small feature will add nothing to cost or schedule. Understand project trade-offs and make decisions regarding objectives on the basis of rational insight. Try to prevent project scope and feature creeps by implementing effective scope control methodology.

5. Unrealistic time or resource estimates: Many times project managers makes costly mistakes while estimating time or resources. Always work in a collaborative environment with the team and have the team buy-in and also consult with the project stakeholders as much as possible while preparing the detail project scope statement so that you do not make costly mistakes while preparing the WBS. Also employ effective techniques to estimate the amount of time each activity is expected to take. Be careful not to (common mistake new project managers make) use linear approximation when estimating the schedule For example, if you double the number of developers, you can cut the project time in half. In reality, doubling the number of developers produces a non-linear result.

6. Improper delegation of task and responsibilities: Many times project managers fail to delegate task and responsibilities to the team such a way that it should fit a team member’s job description. Organize the team such way that everybody should work under his/her own specialization so that the team as a cohesive whole performs the work diligently and within time and budget and thus raise efficiency above standard.

7. Lack of executive support and user involvement: Carefully listen to the executive management and the project sponsor and try to find out whether they have reservations about the project. If so, what is their vision for the project and what are their business objectives of the project. Try to work as an interface between the business and technology sides of the company so that you help our company align business with its projects.

8. Failure to communicate and act as a team: Projects sometimes fail due to improper communication.  A great deal of a project manger’s time is spent on communicating. We will discuss more about communication strategy in step-2.

9. Lack of proper risk management: Another potential cause for project failure is the IT managers’ inability to categorize all the risks qualitatively and quantitatively and implement corrective measures. Identify past, present and potential risks that the current project faced, facing or will face in the near future. Carefully and methodically categorize all the risks qualitatively and quantitatively and implement corrective measures. Assign one or two persons from your team as risk owners. These persons identify the risks, discuss the risks with the team and the project manager, find solutions and implement them.

10. Inappropriate skills: In this rapidly changing, technology-driven business environment and the constant changes of technology make it hard to predict skills the IT department will need. Almost all large IT projects require a diverse range of skills. Many teams lack the breadth, and depth they require.  Plan proactively for your resource requirements and make sure that everybody works under his/her own specialization. Have a solid plan for the skills your project requires. Work with your HR manager to evaluate all alternatives, which may include but not limited to hiring contractors, outsourcing, providing training to existing team members etc.

In step 2, we will discuss about communication and how to have a solid communication plan not just a strategy.

Technorati Tags: best-practices, change-management, communication, project-management

from Lumaxart

As Mark Twin would have said, “Everybody talks about teamwork but nobody does much about it.” Teamwork is the Holy Grail of manufacturing and sales/marketing, as much as for sports. But, like the Holy Grail–and despite claims–few know exactly how to create it.

Teamwork exists, but it cannot be sought directly and cannot be commanded or demanded. It occurs as a synergy when each person of the incipient team understands his/her assigned task perfectly; knows how to do–and does–the assigned task in cooperation with others on the incipient team. Teamwork is essentially task-skills oriented. Our willingness to work with others depends on both their task skills and our trust in those intended- teammates’ skills and commitment. Trust and teamwork cannot be coaxed or demanded or bludgeoned into being.

Known–but unrecognized–corroborations from real life:

• Decades ago, the Hawthorne Effect indicated that employees want to help you succeed. Stop exhorting people re: teamwork. Stop bullying. Stop wishing. Start teaching them how to perfect their assigned tasks and encourage their bonding. Then they’ll be ABLE to do the team’s assigned job!
• A football team coach (we consider a bully) depended on tongue-lashings to “energize” his players and keep them in line. One defiant player wore a sponsored headband, employing a loophole not appreciated by his coach or League’s advertising contract: a finger salute to the coach. But the player knew his task and did it well; and his teammates trusted him to do it. The team won their share but also lost many. That’s sports; not spectacular.
• A Chicago basketball team coach and Zen enthusiast ‘encouraged’ and ‘inspired’ his people, perfecting their task skills. They trusted him, their own skills, and their team-commitments. . .and won multiple national championships.
• When Kobe and Shaq had a long-running feud, the press knew; their early ballgames didn’t show it. Each man knew his task on the court. Each knew and valued the other’s skills and expected that he wouldn’t cheat the team in order to feed the feud. Attitudes changed; break-up followed loss of hoped-for fourth championship. Task skills weren’t the problem!

Don’t ‘demand’ teamwork. That’s the cliche theme of too many sales-related “motivational” films and programs. Film producers (and their staff or free-lance writers who lack corporate training skills) lean on teamwork cliche: “Just do it.” It’s safe–for writers. But worthless.

It’s okay to cheer. Cheers are no substitute for substance. See cheerleaders at every ballgame. How many points do they score?

The single best-selling motivational film of all time is “You Pack Your Own Chute,” by Dr Eden Ryl. No ‘go-team-go.’ Just a psychologist’s view of our need to take responsibility for our own actions. Serious stuff, intelligently presented. “Chute” is still selling, after 30 years. Ryl’s competitors point out that the film’s hair styles and clothes are old. Genius! Why not make a better film? PS: Greta Garbo’s and Charlie Chaplin’s hair styles and clothes are old, too. Moral: View any film before you book it!

Performance skills are scarce. Apparently, expertise requires about 10,000 Hours of “deliberate practice,” according to recent literature and findings. Search “10,000 Hour Rule” on either “Advertising Age” magazine or Google.

Strange ideas, ours? They work: They were developed with well over 12,000 hours of this blogger’s hands-on experience (office hours, plus reality-hours with conventions) and have been proved effective by clients, columns-readers, and other users.

Harold Geneen (once of ITT) wrote “The Myth of Synergy.” Synergy is not a myth–Geneen was criticizing the managerial fad, not the phenomenon. Like teamwork, synergy cannot be sought directly. No synergy in your incipient team? Is their mutual-commitment genuine or just a slap-on-the-back-and-a-beer when watched?  Given mutual concern for the welfare of competent incipient-team ‘mates’ who commit, synergy can take over. Teamwork is an accumulation and accretion of smaller successes in task/job competence–plus the will to do the job with others! Plus our trust in the whole.

Because of numerous failures with empty, but expensive, electronics-based training and distance-learning programs, the meetings industry has been back-tracking. About yr2000, “Training” magazine began pushing that backtracking with challenges. Available:

See www.meetingsCavalier.com; ‘Titles’ page’s ‘Final Thoughts’ segment cites many “Training” magazine attacks on the industry’s sacred cows, detailing the range of meetings-industry problems and biases.

Control of your own meetings, training, team-building, and related group-communications programs depend on your brain, not your budget or technology.

With those read-recommendations accomplished, you will have a fighting chance to construct program agendas, message/contents and tools that themselves have a fighting chance to communicate, train. . .and build teams.

At lower dollar cost. Forever!

Sometimes, you have to break the rules to get things done!

As we go through our lives we are subjected to numerous rules – as kids, as students, as workers and as adults living our everyday lives.  As program managers and leaders, part of our responsibilities is to lay down some rules by which to guide projects, by which teams work together and by which products are built, tested and released.  However, let’s not forget that the reason we have rules is to get us to a destination.   There is a favorite quote of mine which I invoke to remind myself of this principle:

Hell, there are no rules here – we’re trying to accomplish something.  Thomas Edison.

The program manager needs to know when to go by the books and follow the TL9000 (or your favorite development) process and when to let loose and have the team go off and run as fast they can.  I once worked with a program manager (let’s call him Joe) who could not tell the difference.  He was a ‘by the rules book’ type of leader – and that actually got in the way of us getting our jobs done.   We ended up getting to our destination despite Joe.  Here is the story.

Joe was responsible for leading a project on which I was one of the engineering managers.  We started out with a reasonable plan, and had regular program meetings, with status, minutes and action items that Joe would track.  Along the way, two things happened.  Our management wanted us to adopt a new development process.  And, at about the same time, we also had the inevitable ‘technical bump’ in the road that required our attention.  The new process rule required a detailed unit testing plan be documented, and signed off at completion prior to handing off to the QA team.  Joe was focused on tracking this new process requirement and getting the test plan documented.  The engineering team was very concerned about the bump.  Without addressing the bump, there would be no substantial development or unit testing to speak of.  However, Joe had it in our project schedule that the unit test plans would be done by a specific date and tracked that religiously at each meeting.  Joe also had very little domain knowledge and despite the team’s efforts to educate him on the criticality of addressing the problem asap, he continued to focus on the dates and the schedule.  Joe was following his rules book – the established project plan.  The engineering team decided to take matters into its own hands, and we held shadow program meetings without Joe to address the bump and quickly fix the key technical issues that were hampering our progress.  Joe’s rules were getting in the way of work being done.  When the crisis was over, I gave Joe some feedback that he needed to be able to adjust his plans when bumps came along, and bend the rules to meet our most critical goals.  To do that, he needed to learn more about the domain and understand the business of what he was program managing.  However, I hear he still manages the same way. Sigh!

Focusing on the rules and mechanics of program management helps keep things going.  But a good program manager needs to have at least a basic understanding of the domain and be prepared to apply rules or break the rules in order to get things done.  At the end of the day, the customer will not pay if we don’t have a good product, but followed all the rules!

Is this even possible?

How a team feels impacts its productivity and business results.  Imagine if the acrobat above was having a bad day… the results would be disastrous!

A key ingredient that shapes team effectiveness is its culture and having a sense of community.

Geography plays a huge role in shaping culture. Communities that live together use a common language, have common values and rituals. Everyone in the geographic community adopts certain cultural traits that allow them to work together and succeed in their environment.

Imagine if that same community is distributed across different geographical zones and asked to work together on common goals. It will be challenging to say the least. Everything from basics such as values and knowledge, to accepted rituals, to simply working together becomes more difficult. Add different time zones into this mix and you have the challenges faced by many project teams today.

Distributed teams are an inevitable part of our world. Today’s business reality demands that the best talent be leveraged for a project – no matter where they are physically located.  How the project is partitioned, and how the team is actually organized, plays a big role in whether the project succeeds or fails.

In the initial project planning, consideration of physical and virtual teams is an important aspect of setting up teams and projects for success.

In general, a collocated team is more effective for highly intense, fast paced projects that require daily interactions.  People can more easily tune into the nuances of the human network, build trust and form bonds – all of which are critical in problem solving and innovation.

There are definitely situations when virtual teams are practical.  For example, if the project components are split at a macro level such that it does not require daily or weekly calls and negotiations, it is likely that infrequent discussions suffice.  In these situations, there is no need for physical collocation. There are excellent advances in communications technology, such as web conferencing, that make it possible to have the as-need communications.  In fact, this would be more cost effective in this scenario.

It all comes down to judgment.  That judgment comes from you – the program manager.  The key is to bring such factors into the project planning and execution.

What has been your experience in balancing live and virtual teams and how that has impacted your project planning?

With an increase in geographical and cultural distance the aspect of “trust” becomes all important. When people have never met, there are two mechanism we can fall back on:

• reputation: what others are saying about the other person, and
• trying to read “telltale signs“, look for behavior or other marks that they identify with trustworthiness.

This second mechanism might be as simple as being friendly and saying “hello” every time you see someone down the hall. People attempt to detect the tell-tale signs of trustworthiness not only based upon behavioral markers that society associates with it; it has also to do with the similarity of the other with you. Persons that are more viewed as being equal or “the same” are more likely to be considered honest and sincere towards you.

Back to “reputation”.

Technology has brought us the challenge of working with people we really, really, really don’t know, but it has also provided us luckily with a reputation mechanism by transparency. The question we all ponder: does this help? Is the transparency and the resulting reputation reliable? And does transparency lead to more ethical behavior?

As for the first part, that one is easy: every system can be manipulated. Especially on the web. Entire PR companies are in existence simply to provide “a good vibe” about a person or company on the web. All the “experts” are recommending each other. The eBay seller reputation system has been mislead before by people selling stuff for a penny just to get the needed recommendations. The system is just as reliable as the people using it.

But even when the system is working properly, even when transparency makes sure people’s behavior will be noted around the globe, this doesn’t mean you can take the benefits from it in your project or business. Although with a good reputation a lot is to gain, having a bad rep puts a lot at stake. So people will play things save. They will create low-risk behavior, resulting in the end into mediocrity..

A good example of this is illustrated by the following:

“While the typical CEO is only too happy to pocket the lucrative financial rewards that come with the mantle of leadership, some seem reluctant to accept this degree of accountability – especially if it means personally taking the rap for non-compliance with the law. I guess not many corporate heads are convinced that a minimum-security sabbatical in an orange jumpsuit will be as good for their careers as it seems to have been for Martha Stewart’s.”

Humans have a preference to fail conservatively. For me personally this is a surprising one. However, I do recognize it. The idea behind this is that people would rather choose an option that they know, that they have done in the past, EVEN if the outcome is likely to be unsuccessful, than try something new, where the outcome may be positive, but unsure. If they fail, they can also hide behind the notion that they did everything everybody else is also doing.

Let’s hope that the future doesn’t only contains of people conning the reputation systems by “influencing” information that tries to pose as “transparent”, and people that fear the system and stick to mediocre accomplishments.

Regardless of how another individual acts or behaves, it is important to reflect the same feelings and moods as the other person; at the very least show an appreciation for how they are feeling.  Even when those feelings are negative, for example, the other person is tense or angry, you need to acknowledge and respect this in order to build rapport and to move the conversation forward.

When dealing with aggressive behavior, breathe evenly, keep calm and stay quiet.  Think, “This person is behaving aggressively, I’ll deal with it in an assertive manner.”  Ask open questions:  Who, What, When, and Which.  Do not ask Why; this will often place someone exhibiting aggressive behavior into a defensive mode, resulting in more aggressive behavior. Asking Why appears to question motives rather than gather information.  Level with the person, explain how their behavior feels aggressive and describe how it is having an adverse effect on your and/or the team.

When someone is behaving aggressively, they tend to expect disagreement.  Why not slow them down by giving an unexpected response?  Fogging is a technique used to sidestep their issue while retaining your viewpoint and integrity.  For example, if someone said to you, “That was a pretty stupid way to behave in the meeting.”  You can respond in an unexpected manner by saying, “Yes, I can see that you think it was a pretty stupid way to behave.”  The word “yes” takes them by surprise, slows them down and can reduce the tension.  You are not agreeing that you behaved stupidly, only that you can see that that they think so.

We all see better when the fog lifts.

Lisa DiTullio, Principal, Lisa DiTullio & Associates, www.lisaditullio.com

I had the opportunity to speak at the PMI Congress this year.  My presentation, called Expected Behaviors for Project Team Performance:  Road Rules, Not Road Rage introduced a set of ‘good behaviors” for teams to consider and an easy way to enable team members to reduce the “noise” which occurs among team members.

Determining the “right” set of behaviors to support productive teamwork is never easy, as team dynamics are intricate and difficult.  Defining a set of behaviors to best support teamwork must be articulated in a universal language, ideally because these behaviors need to be owned by the entire organization, not just project teams.  When set at the enterprise level, the introduction of expected behaviors sets the framework for ensuring these behaviors are a means of conducting business, not just a set of words hung along corporate walls.  Ideally, the entire organization must believe in the power of teamwork and to experience improvements in project outcomes and project performance as a result of strong teamwork.  If the company as a whole isn’t quite on board, start without them –introduce the behaviors to your project team.

 These Expected Behaviors have universal appeal, regardless of company size or corporate culture.  In other words, this set of team behaviors appeal to a broad audience because they are clear, easy to understand, and are comprehensible to diverse project teams, regardless of member position or title. 

The set of expected behaviors that have universal appeal to project teams are:

• Treat others with dignity and respect
• Support and promote intra- and inter-departmental teamwork
• Understand and consider the needs and impacts of your own work on others
• Demonstrate an ability to problem-solve and make timely decisions
• Actively seek and receive feedback for improvement
• Consistently share knowledge and information

 Introducing Expected Behaviors to project teams has a simple premise:  Project work is conducted through groups; groups tend to be complex challenges from a management and communications point of view; if project teams come up with some ways to improve group dynamics, they can enhance group performance.

Conducting a Rules of Engagement exercise will allow team members to develop an initial contract that describes how they will treat each other with dignity and respect.  Since the meaning of “treating others with dignity and respect” varies from individual to individual, this tool will help the team identify and discuss the various elements of behavior that are critical to the success of ongoing interactions.  The Rules of Engagement exercise focuses on six key areas of behavior:

• Basic Courtesies
• Operating Agreement
• Problem-Solving and Decision-Making
• Accountability
• Conflict Resolution
• Leader’s Role

In a team meeting, schedule extra time to focus on this.  If a team does not dedicate time to this exercise, it will never happen.  Many teams schedule a special session dedicated solely to Rules of Engagement.  In this meeting, team members brainstorm and record a list of key behaviors that are important to them and that best support operating agreements.  Consider asking such questions as, How do you like to work?  What is your work style? What strengths do you bring?  What type of behaviors annoy you?  What kinds of behaviors take us off track or reduce our effectiveness? Allow time for discussion of the key areas and behaviors that the team wants to adopt.  Ensure all voices are heard.

Run through each of the six key areas; all are important.  However, teams may find that not all have equal weight.  For example, Conflict Resolution may be more important to the group than Operating Agreement.  Focus on getting through all areas while seeking common ground for consensus.  Be sure to confirm that each area is complete before moving on.  A team leader may need to solicit input from quiet team members; not everyone will have the same voice.  As facilitators, it is important that team leaders acknowledge others’ contributions to the discussion before relating their own remarks.  Never distort others’ views in order to advance your own.  To be successful, the results of this exercise must represent the team’s collective input.  It is not unusual to invite an external party to facilitate this discussion; having a non-biased, unattached person lead the Rules of Engagement discussion often frees participants to share opinions freely.

Once the group decides on the key areas of behavior, they document and post their Rules of Engagement at every meeting as a reminder.  Depending upon the duration of the team, the group can decide if the agreement needs to be refreshed; often teams do not return to their agreement unless there are challenges in a particular area or significant turnover in project team membership. 

For skeptics who perceive this activity as nonsense and a waste of time when there is constructive and important project work to deliver, keep this in mind:  Teams who conduct this exercise indicate their teams are positively impacted by the experience.  Communication and working relationships improve; team members become more aware of behaviors toward others, more aware of others’ roles, and better at seeing different points of view.  Team who adopt Expected Behaviors say the exercise creates a more comfortable working environment, meetings are more productive, and teams are more efficient in meeting deliverables.  The big surprise for most team leaders is the realization that the activities are not time-consuming, do not slow down work, nor do they stifle team energy or limit lively and productive discussion.

According to organizations who have introduced Expected Behaviors on project teams, participants say it has made a difference.  Follow-up survey results suggests the Expected Behaviors Team Survey tool very easily identifies team strengths and weaknesses and the Rules of Engagement exercise enables project teams to flag and fix team behavior smoothly.  Taken together, this is an effective preventive course of treatment for successful team dynamics.

 Lisa DiTullio, Principal, Lisa DiTullio & Associates, LLC

Here are some things I came up with off the top of my head, but I’m certain that there are many more.

Practicing Servant Leadership – If you’ve gotten into Project Management for the power and the glory, think again – being a Project Manager means being at the beck and call of everyone involved in the project, from the project sponsor to the lead developer to the QA tester. It’s being able to remove the obstacles that team members face on a daily basis so they can focus on getting the work done. It’s truly serving the team, and the project’s best interests, not focusing on your own needs.

Becoming a better Strategic Planner – No one can truly predict the future, but as Project Managers, we need to work on anticipating the unknown, mitigating risks, thinking about what could happen. It’s been my experience that the worst can and *will* happen so spending time dreaming up strategies on dealing with the unpleasant “what-ifs” is never time wasted, and can only work in your favor. If possible work on being proactive rather than reactive – two steps ahead, instead of one step behind.

Being a great Communicator- This means not only being able to disseminate information to upper Management, stakeholders, and externally, but being able to talk with the team one-on-one as well as in group settings. Also being able to have the frank, tough discussions when performance is lacking or the overall schedule has slipped; being the bearer of bad news. It’s being able to ask the right questions so you can have as much information as possible in order to make the hard decisions and tradeoffs.

Becoming a better Listener – This is something all Project Managers should aspire to. Encourage an active dialogue with your team, and make sure that everyone is given a chance to be heard. Good listening requires the suspension of our own egos, opinions, and thoughts to make room for someone else’s.

Being Authentic – This means practice what you preach; keeping your word so people know they can count on you; and perhaps, most significantly, not hiding behind that mask of “Super Project Manager.” Be yourself! Own up to your mistakes; say you’re sorry if necessary and mean it. Your team and everyone involved will respond favorably if you’re being genuine.

Being Ethical – This is so intrinsic to good leadership – Setting a credible and ethical example to follow and having integrity is everything. Enough said.

Being tolerant and able to see other perspectives – This means being open to considering a wide range of possible ideas and respectful of divergent points of view, even if they differ from yours. Some of the most valuable contributions I’ve ever had to tackle solving project issues came from the most unlikely sources (difficult and annoying personalities but brilliant minds.) So staying open to others’ ideas can only benefit all concerned – you, the team, and the overall project.

Creating a compelling and collaborative Work Environment – Projects are hard endeavors and there are times when you just want to throw up your hands and be done. Having a good work environment where people feel empowered to be themselves and open up about what’s really going on; where team members aren’t afraid to ask for help; where everyone is treated with respect – all of these are paramount to project success. It’s been my experience that an open forum keeps folks engaged and less likely to jump ship when encountering rough waters. And build team morale by recognizing work-related achievements; everyone will appreciate the heartfelt “thank you.”

Having and keeping the vision alive - This means being the keeper of the flame for projects; the cheerleader and evangelist for the project, particularly important when it’s a long haul and your team members are feeling overwhelmed from a huge workload and multiple competing priorities. It’s the PM’s job to rouse up the troops and get things moving, inching forward ever so slowly if you have to.

Thanks for reading! And always, many happy trails to project success.

Lisa

–
Lisa Winter, PMP
Strategic Product Management
Effective Project Management
Business and Systems Analysis
Multilingual & Multicultural
Relationship Building
Small Companies to Fortune 500

Technorati Tags: Accountability, best-practices, Career development, communication, Getting-Things-Done, Leadership, management, Project-success, Risk, soft-skills, Team-building, Vision