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

by Timsamoff

Even if you believe that everything from dating to contact with God can be managed on the computer, that ain’t quite true. Despite the push for technology in every operation–and despite our first endorsement of (still-sequence) video-conferencing (VC) in a 1983 book, you will want or need to meet face-to-face at times. The message itself will determine. Caution: Don’t believe the opinion-mantra, “It’s gotta be face-to-face.” It ‘don’t gotta be nuthin’ but proper. ‘Proper’ requires thought. Meeting settings must be proper for given messages. Meetings such as skill training are best done in small groups. Military ISD (our source) presents an algorithm for settings-selection.

Every meeting-support technique has strengths and weaknesses; and one of those choices will work better for your meeting than will any others. Selected options by purpose, not dart-throwing. For key tools (pro & con) that can be used to support your message, check a reprint of our ’70s article for basics; slight augmentation needed now. See the original article on our website: click ‘Recognition/Industry’; below Note: ‘AOM & Early Mag Articles’; see article from “Advertising & Sales Promotion” magazine (web p8 of 22pp).

Specifics there are valid unless noted here:

Re: Charts, drawing, chalk-/chem-boards: Verbatim, plus: Computer-aided visuals, now.

Re: Photographs: Verbatim, plus: Also computer-aided visuals, now.

Re: Books, booklets, outlines, tape recordings or disks: Verbatim, plus: Again, computer-aided visuals, now.

Re: Demonstrations and sociodramas (constructed plays, not believed):  Verbatim, plus: Less convincing if computerized.

Re: Role playing: Verbatim, plus: Valid only if live, not computerized.

[Quoted further]: All of the above tools [in the entire original article] have intrinsic value of either a permanent or intermittent nature. By contrast, visual aid equipments are enabling technologies but have no independent value whatsoever! Today’s purveyors have neglected to mention your non-technology options. [End reprint.]

Three significant points:

1. The computer is extremely valuable, of course. However, the eye does not prefer, or distinguish between, the sources of usable graphics. Therefore, slides and printed materials are still valid.
2. All graphics, no matter how simple or complex, must appeal to participants’ understanding of your message’s basic concept (right brain)…to interpret, as a further explanation of the spoken/written words. On-screen words (left-brain) are not legitimate visual ‘aids’ unless the words themselves are at issue. That’s rare. Color is not essential if the graphic itself is clear. (For multiple US military findings: ‘Recognition/Industry’ button, below Note; see “FirstTake” magazine (p13 of 48pp).
3. In meetings/seminars/training, etc, eye cloys more quickly than ear. For long presentations of non-technical material, ear is the preferable recipient. Complex/technical stuff needs visual help.

Decide which of the article’s techniques best suits the purposes and requirements of your message; select the proper support materials and technologies; determine the proper setting for the message, purposes, and audience size. Proper settings might include hotel space.

Audience size is a factor. Don’t guess according to general crowd-control principles: Best size for the meeting purpose, time allotted, and optimum use of likely setting? Military ISD algorithms work well.

You can’t coach a roomful of people in any but a cursory way. Adequate? If not, how enhanced? Smaller break-out sessions suffice? Can/will managers supervise, back at offices? Enough authorities to run multiple break-outs? If not, don’t fake it! Choose: one central session or multiple regional repeats?

Every meeting-caller usually wants to reach everyone in his/her target audience simultaneously. Great, if simultaneity is a valid factor. Bad, if it causes unnecessarily-large convocations. Large meetings feed on their own size and thereby cause additional expenses.

Decades ago, American Express found about two-thirds! of the average corporate travel budget consumed by annual central sales meetings. Computers can change that somewhat: Significant savings are possible via Video Conferencing. Computer programs suffer drop-outs–just like schools or sleepers in central meetings. Also decades ago, “Sales & Marketing Management” magazine’s  ‘Survey of Selling Costs’ (annualized) found multiple regional sales meetings always to cost less than one central meeting.

Unless simultaneity is essential, hold regional meetings whenever possible. That’s more demanding of meeting-caller time, short-term, but it’s also less pressured: Local offices can usually handle most or all logistical needs.

Although computer software now allows collaboration among editors and other specialists, software enables only editorial ‘collectivizing.’ Expertise and authority are NOT created by collaboration–that’s round-table discussion from distant chairs. It does save time and travel.

Many meetings can be held in-house. Choose smaller regional facilities if you hope to avoid in-house interruptions. To manage any such meeting, embargo all phone calls, in or out. You might permit exceptions for the Chairman of the Board and CEO, but only if you value your job.

If you agree on anything with a hotel rep, get everything agreed in writing. All chains and most large facilities have an “in writing only” policy in case of disputes…common when any third party over-stays its allotted time and delays your set-up or scheduled session.

Selected reprints from “AOM” were Copyright either 1970-71, Crain Communications; or 1971-1973, “Sales Management” (later: “Sales & Marketing Management”) magazines.

For more information and a proved form for comparing criteria and selecting hotel facilities, see our website: www.meetingsCavalier.com. Click on ‘Business Writing’; then ‘Titles’ button. At book “Sales Meetings That Work,” click on ‘Chapter 18,’ complete segment. Dow Jones-Irwin’s “SMTW” cover shows under ‘Recognition/Industry’ button.

Every meeting element is unique but interdependent. It must be gauged in advance so meeting-callers understand the meeting’s Gestalt. Only then can meeting-callers determine the relative value and requirement of the individual elements, as well as the whole. Don’t try to wing-it. If there’s no Gestalt, you can’t buy protection for any intended message. So severe and so frequent are business meetings failures that one training company placed a full-page ad in a related trade magazine to try to shift blame away from the technology, the supposed ‘answer’ to all ‘non-existent’ problems (“Training”; Mar-Apr,’09; page 15).

Meeting-Managers (and all -callers) must regain control of the message before control of meetings and wanted-results is possible. Again, Meeting Manager vs meeting planner. Management and control begins with your understanding of your message needs, not hotel and airline reservations. Logistics are important if unavoidable but contribute nothing to message-understanding and fulfillment.

PERT delivers visualized control of the entire meeting structure. Time-oriented, PERT demonstrates that logistics devour your coordination time. Yet logistics are less important in total than the message’s priority needs.

Recommendation: Use PERT together with the military’s original ISD (Instructional Systems Development) process. That pairing is dynamite!

ISD demands that you know exactly what your message requires and then helps you (step-by-step) to fulfill the dictates of that message. Using PERT, military personnel create workable programs anywhere in the world to answer immediate needs effectively. Commercial ISD disk programs require you to choose among relative strengths and weaknesses of proprietary versions of the military original before you buy. That requires basic knowledge of ISD before you shop. Gotcha!

ISD/PERT requires you to think of every meeting in terms of both its message and its logistics and how they’re best brought together. Why? You can’t make piano music until you’ve learned to finger the keys. These communications keys will harmonize your objectives and results:

Consider every meeting’s needs and agenda before all else:

1. Is your do-able purpose stated succinctly and clearly?
2. Intended response: what should participants logically do as a result?
3. How does the new action differ from old methods and information?
4. What new tools are needed to aid and accommodate new activities?
5. Will those tools be available at your meeting? If not, when?
6. Have you provided practice time with new tools for participants?
7. Have you planned with authorities/designer/developer to produce needed tools?
8. Have you refined your key address to answer every element of message and its true requirements? Unexamined technology is not itself an adequate answer. (A future blog.)
9. Have you determined the proper setting: in-house, local, national?
10. Are you providing logistical support for that setting, if needed? PERT!

With dictates above fulfilled, be confident that meetings will work. You’ll also set standards for The Other Guy, who conducts lousy meetings.

Attention to message is free of cost–just deliver needed time and thought. Too rushed? Remember the adage: “Why is there never time to do it right but always time to do it over?” There’s no second chance with a failed meeting because you might already have disproved your own expertise. Here, their perception counts for more than fact.

Complications involved in creating competent meetings are visible on our PERT Diagram graphic. There, our ten points above are condensed into a single feeder bar in the multi-line/bar PERT arrow.

To download a usable PERT chart, see www.meetings/Cavalier.com; choose ‘Business Writing”; click ‘Recognition.’ Below the Note, multiple buttons include ‘Book AOM and early mag articles.’ Our original PERT Diagram and its notes follow the “AOM” book cover. Find fuller explanations and expanded how-to re: PERT in related books “AOM” and “SMTW.”

For more information re: ISD, click ‘Titles’; see “Common Sense ISD” book, a complete how-to. The “ISD” book webfile offers actual (but partial) opening Phase I (of 5 Phases), a brief example of military ISD’s step-by-step method.

Specifically, he was referring to the problem of padding in estimation for tasks. Being new to software industry, he was not sure whether the estimates provided by his team members were accurate or padded.

The padding refers to extra time added to a schedule that isn’t really needed but that is added just to feel confident in the estimate. The impact of padding could be significant on project schedule. The quality of the estimates directly affects whether or not the project can meet scope, cost and schedule commitments. The accumulation of padding all the tasks can result in overly cautious project schedules and uncertainties across the project schedule.

According to one estimate , the average company completes only 37% of IT projects on time, while only 42% finish on budget. Much of this is attributed to the difficulties in gathering accurate estimates of effort.

The reasons for padding the estimate could be many. The resource might have multiple projects that they work on. They have overlapping work from those projects. They have nonscheduled time or they are given conflicting priorities. Rita Mulchay explained it nicely in her PMP preparation book by summing up team member’s thoughts:

“I have no idea how long it will take. I do not even know what I’m being asked to do. So, what do I say? I will make my best guess and double it! ”

There are a number of approaches project manager could take to address the issue of padding:

• Use expert judgment. Let the experts review the estimates provided by estimators. The experts can identify cases where the estimation doesn’t seem right. These could be senior or principle software engineers within the company.

• Use estimating techniques such as stochastic estimation. Ask team member to provide a range of estimates. For example, asked member to come up with task estimate for best case scenario, worst case scenario and most likely scenario. Using the 90% confidence factor, one can come up with reasonable estimate.

• As project manager, you should provide sufficient time to estimator. If estimator is asked to estimate a task on the spot, estimator may feel pressured and provide a number just to get us off their back. Estimators should be provided enough time and encouraged them to think carefully and thoroughly to come up with estimate.

• To minimize the schedule risks of your project, it’s

• better to apply the padding at the project level instead of at the individual task level. This is commonly referred to as buffer. Make sure to communicate about project level buffers to all the team members to keep everyone on the same page.

• Instead of asking for estimation of task duration asked in terms of task effort. This helps avoid introducing padding into the estimation process. Also, understand that people are human beings and no one works hundred percent of their time. When estimator provides an estimation of the effort, the numbers should reflect continuous, nonstop work.

Over the weekend, I facilitated fabulous workshop on Advanced Microsoft Project sponsored by PMI Silicon Valley chapter. According to instructor, every time software developer is interrupted it takes 14 minutes on average to get back to development work.

Additionally, I have experienced that software quality assurance engineers generally estimate efforts over cautiously whereas software developers tend to provide over-optimistic estimates. Understanding and factoring such elements can help improve accuracy of estimates.

Lastly, for medium to large projects project estimation software such as Cost Xert or KnowledgePlan can be utilized effectively. There are also other methods such as System Development Life Cycle (SDLC) which consist of a set of best practices that lets engineers break projects down into recognizable and repeatable steps, processes, tasks and outcomes, each of which can be accurately estimated.

My most extreme week was in March this year. One weekend I am flying to the Netherlands to spend some (most likely last) days with my best friend who was losing her battle with cancer, only to receive the shocking news at my stopover in Chicago that she didn’t make it through the night. My plan to say goodbye to her became a final goodbye at her funeral. That very next weekend I find myself in Japan to assist in a leadership workshop as a way to hopefully start a long term business relationship. The people are amazing, their gratitude and sincerity overwhelming. Talk about emotional low and high within a week.

In July this year, I realized that I needed to kick myself in the butt. My objective has always been to live a conscious full life; however, 2008 and 2009 had managed to get my spirit down. In the end, we are the architect of our own life and I realized that in my friend’s honor (and others who have lost their lives), I should live every day to the fullest. Even though this might have been a tough year, we should consider ourselves lucky for being born in a western country. That by itself puts us in the top 5% level of lucky people in this world. Whatever we deal with on a daily basis in our work and lives is nothing compared to those who try to survive on a daily basis without food, water or simple basic needs.

Only this morning it dawned on me that we are not only closing a year, we are closing a decade. A brand new decade is starting in four days. So instead of just reflecting on the last rough year, take the time to reflect on the last decade. Count your blessings and if there are areas for improvement, you are the only one who can change your life and improve it. Change is scary but also always holds opportunities.

Take the Agile approach to life, which means using your ability to both create and respond to changes in order to succeed in a turbulent business environment or live a satisfying life. During the last week of 2008, I blogged about living life smarter (read here): next week I am meeting up with a very good friend of mine to look at the new decade ahead of us to go through a goal setting exercise, prioritize them and start executing. I invite you to do something similar to chart your course through the year and decade ahead. Don’t wait.  Take control of your life and take action!!

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?

Table of contents for New Thoughts on Risk Management

1. Latest Thoughts in Risk Management (or What I Learned from going to the Risk Symposium)
2. Risk Management – What about the Opportunities?
3. Risk Register – Short & Sweet or Extensive & Complete?
4. Risk Management – Paradoxes and PLC

Two of the keynote speakers at the PMI Risk Symposium provided insights into how different risks change in priority over a product lifecycle (Esteri Hinman) and how effective risk management encourages poor risk management (Payson Hall).

Risks change over a product lifecycle

Esteri Hinman PMP (from Intel) presented that there are different functional groups involved over a product’s lifecycle with differing levels of risk management awareness:

• Product Development: impacts related to cost / schedule / scope; proven processes; mentors available
• Manufacturing and Delivery: impacts quality and revenue; processes known
• Planning and R&D: “We don’t have any risks”; Opportunities reign; Risk Management not widely accepted

Notice the difference in risk management attitude and knowledge?  Would thisenvironment encourage  product development success?  Well, it won’t make it an easy path…

Across the Product Lifecycle, she characterized five “faces” of risk:

1. Business:  Risk related to the eventual business value of the product
2. Technology Risk related to the maturity of the technology required for the product
3. Product:  Risk related to the commercialization of the product
4. Development Risk related to the ability to develop the product
5. Manufacturing: Risk related to the manufacturing processes of the product

The relative importance of each  “face” changes over the lifecycle and that a”Risk Footprint” is unique for each product.

Imagine a “wave” moving towards a beach, where the wave represents one type of risk. The beach is when the wave is minimized, similar to the level of risk when a product has started being delivered to the customers.  Imagine five “waves” at different intensities and on top of each other – that is a Risk footprint.  And imagine your company is riding the “surfboard” on top of those waves. Got the idea?

Her final point: “It’s about the Business”.  Thanks to Ms. Hinman and Intel for this insightful presentation!

Risk Paradox: Why Effective Risk Management Seems to Encourage Poor Risk Management

Payson Hall’s topic provided great understanding into the lifecycle of a organizational risk management practices.  Not doing justice to his creative and well-organized presentation, the lifecycle was described as:

Nearly non-existent –> Scattered & Episodic –> Coordinated & Increasingly Effective –> Calcified & Process-Bound –> Decaying & Sporadic –> Nearly Non-Existent

So why does this cycle occur? One possible cause he described as Framing bias. If we were asked to choose between 80% chance of losing $4000 or 100% chance of losing $3000, most people would pick the former.  His evaluation of this situation:

“Humans aren’t risk averse, but are “losing averse” & perceive possible losses as a greater threat than possible gains.  We have a bias toward taking greater risks to avoid losing.”

There are also challenges to maintaining effective management practices.  One I particularly like is the fact that “Risk Management isn’t Sexy”.  Comparing a fireman to a fire inspector, who do you think saves more lives?  Preventive measures aren’t attractive – heroes are.

His suggestions for stabilizing this effect:

• Implement in slow & deliberate steps
• Seek executive input about which risks to address; Keep them involved
• Take credit for wins AND losses; don’t oversell the benefits

These suggestions are useful for any type of long term organizational change.  His main point was to keep telling people how risk management is helping the business, all the time.

If you have a chance to see Payson’s full presentation, make the effort! It will be worth it!

Technorati Tags: product life cycle, Risk

Table of contents for New Thoughts on Risk Management

1. Latest Thoughts in Risk Management (or What I Learned from going to the Risk Symposium)
2. Risk Management – What about the Opportunities?
3. Risk Register – Short & Sweet or Extensive & Complete?
4. Risk Management – Paradoxes and PLC

Continuing on the project risk vs. opportunity concept, Tom Kendrick’s presentation dove into the identification and management of opportunities that exist in all projects.  Called “Disentangling Project Opportunities and Risks“, opportunity is defined as a “favorable juncture of circumstances” while risk is just “bad”.

Some key points of his talk were:

• Scope Opportunity Management is about merging a deep understanding of the user needs with available technical capabilities to create the best deliverable – not necessarily with one first envisioned
• Involve Project / Program management during the objectives and project selection phases; Planning is a fertile source for risks as well as opportunities
• (Opportunities)  This is about choice, not uncertainty.

When dealing with uncertain project opportunities “Luck is what happens when preparation meets opportunity.”  This has happened in my product development experience when my team had suggested an opportunity to reduce the material cost.  We created small experiments and evaluated the results to our criteria and demonstrated that we could lower the product cost without affecting the performance.  Win-win for everyone!

Once the opportunities are identified the management is similar to those of risks, but with a different attitude (more positive rather than negative):

1. Assessment is in terms of Likelihood and Gain (instead of Loss)
2. Tactics now become Exploit / Enhance / Share (instead of Avoid / Mitigate / Transfer)
3. Opportunities can increase or decrease risk.  There may be uncertain probabilities, uncertain impacts or  both and should be assessed and managed.

Are there benefits for you (the PM) if you look for opportunities in your project?  Possibly. With uncertain project opportunities,  Tom’s observations (for most projects):

• “Success has many fathers, while failure is an orphan.”
  • Credit for something that goes well is grabbed by those in power
  • Blame for disasters falls on the PM and team.
• “No good deed goes unpunished”
  • Delivering miracles may result in unrealistic future expectations.

I’d choose to delight my customer and exceed their expectations.  If this is can be accomplished by identifying opportunities as well as the risks, count me in.

Tom, thanks for your insights into the other side of Risk.

Next, The Paradox of Risk Management from Payson Hall…

Technorati Tags: project-opportunities, Risk