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.

Image: EdgeDonkey

We all have been in the situation where a customer or team member asks to add a feature or upgrade the quality of a certain item. We often agree to do these favors because we find ourselves unable to say “no”—driven by our desire to please or a preconceived notion that we do not have the option to say “no”.

Favors happen on projects because many of us like to help other people. Doing so makes us feel good. It can make us uncomfortable to say no or to make tough decisions. The problem with doing favors is that it can have a domino effect or even start the project on a downward spiral. One favor begets another and before you know it, you have lost control over the project scope, budget, and/or timeline.

The construction industry has made controlling favors an art. Anyone who has ever built a house or has done some remodeling knows that contractors do not do favors. Any requested change is discussed, the work estimated, a cost assigned, and a new timeline approved.

Project managers in other industries would do well to take a lesson from the construction industry. Rather than simply saying no when someone requests favors, make the price tag visible so that the right decisions and tradeoffs can be made. Skillful project management is not about trying to please one person at a time; rather, it is about satisfying the majority of the project stakeholders involved and most importantly to provide customer value. This requires balancing all expectations.

Project management is not a popularity contest.

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

Another highlight (IMHO) of the Risk Symposium was Eldon F. Jones’ presentation on “Risk Register – What is it and How is it used?”

What is a Risk Register?

A Risk Register is a document that lists “all identified risks, including description, cause, probability of occurring, impact(s) on objectives, proposed responses, owners, and current status” per Mr. Jones.  It is an output of the Risk Management Plan.

I have used a variety of Risk Registers and it can be as simple or detailed as you need it to be, depending on your project.  If you want to start doing some Risk Management, I suggest that these are minimum features of the register:

1. Description of Risk
2. Level of Impact on the objectives (rated Low, Medium, High)
3. Probability of Occurring (rated Low, Medium, High)
4. Mitigation (What we’re doing now to prevent / what we will do if occurs)

It’s just enough to identify what to look out for and not so much to overwhelm anyone you show the register to, especially upper management!

Elden Jones’ approach would be good for a very large project / program, since he recommends Risk categories such as:

• Technical, Quality, Performance (Hardware, software, integration) risks
• Project management risks
• Organization risks
• External risks

He also includes scales for qualitative risk analysis, where the values are “placeholders – the scale levels are only rank ordered”.  Probability scales are only “indicators… or guesses, not true probability values.”

Risk Impact, he suggests, should also be scaled, with the ranges of probability linked to quantitative ranges of cost, scope, time and quality.  For example, if the impact on cost is 5 – 10% change, then the probability may be greater 15 up to 45% (equivalent to Medium Risk Impact).

Mr. Jones’ Risk Register includes WBS IDs, Risk Category (such as Client, Human Resource, Mother Nature, Technology), Risk Status, Impact (Scope, Cost, Time, Quality) and Response.

One interesting approach to Response is to distinguish the risk as a Threat or an Opportunity, since different responses would be used.  For a Threat, the strategies would be to either Accept, Avoid, Transfer or Mitigate.  For an Opportunity, the choice would be to Accept. Exploit, Share, or Enhance.  As the Register is regularly reviewed, the risks events are evaluated for probability estimates and the Responses.

Risks should be retired once the threat has passed – would that be great to cross it off the list?

Next: More on Project Opportunities and Risk from Tom Kendrick

Technorati Tags: opportunity, Risk, threat

Tracking Gantt

Project Conference 2009 continues through this week in Phoenix, AZ.  As Microsoft prepares for the release of Project 2010, it’s a good time to reflect on some additional best practices that project managers should keep in mind when using their current version of Microsoft Project.

Know the Limitations of Critical Path Methodology – CPM was developed by the DuPont Corporation over 50 years ago as an effective method to identify activities with no tolerance for delay.  You can use the Gantt Chart Wizard function to display the critical path in Microsoft Project.  One significant limitation with the Critical Path Method is that it does not account for resource constraints, only task dependencies.  Project managers who are dealing with limited resources often find that not all projects can be managed to the critical path schedule.  Incorporating the Resource Leveling feature can help a project manager identify resource bottlenecks in addition to the critical path.  Using the Leveling Delay column and the critical path helps to pinpoint which resources and tasks are the ones to focus on first when optimizing the schedule.

Learn to Compress Schedules Effectively – Project managers are always trying to save time and often utilize many schedule compression techniques.  It’s important to practice each technique in Microsoft Project in order to become as efficient as possible when optimizing the timeline.  One of the best places to start optimizing is in resource reassignment.  When working in a resource constrained environment, reassigning a leveled critical task to an available resource is a great way to save time.  Other compression techniques include applying concurrency (negative lag in Microsoft Project) and shortening duration.  Both of these methods should include documentation (I always recommend on Task Notes) to identify the assumption(s) made in order to fast track or crash the activities.

Achieving Consensus and Understanding Baselines – This is always an interesting topic.  Saving a baseline in Microsoft Project is a simple mouse click – a 5 minute feature review to go over the menu command and which fields are affected.  But it represents a fundamentally important point – the consensus achieved between project sponsor and the team over what will be delivered, who will do the work and what is the agreed upon schedule and budget.  The project manager is responsible for reaching this agreement as a result of the project planning process.  Setting a baseline essentially takes a snapshot of the planning data and saves it for future reference in the tracking and control phase of the project.  The importance of this step within the process of using the tool cannot be understated.

Controlling Projects by Variance Analysis –Here’s where Microsoft Project shines.  Once an effective planning process is completed and a good baseline is set, the Tracking Gantt View and Tracking Table can be utilized to collect actual status and provide quality decision making data for corrective actions.  Fields like Actual Start, Actual Duration and Remaining Duration are far more effective than % Complete.  Team members are much more accountable to task updates when asked for remaining duration or work as opposed to % complete.  Good project managers will go around and gather actual status from team members prior to any status meetings and then use the team meetings for more important activities like problem solving, risk management, scope change control and additional planning.

Supporting Multiple Project Managers –Whether it’s a large well established PMO or a single project manager who wants to improve the way projects are managed in the organization, there are many best practices in supporting a group of project managers.  The easiest place to start is by standardizing many of the useful objects within Project and replicating them to other plans or templates with the Organizer feature.  These objects usually include tables, filters, views and calendars (e.g. to establish working time for various countries).  Organizing a regular company user’s group meeting can be an effective way to share lessons learned and keep everyone on the same page.  Other useful techniques that support project management in the enterprise include Shared Resources, usage of master and subprojects, project-to-project dependencies and portfolio resource management.

For a more in-depth look at Microsoft Project Best Practices at UCSC Extension in Silicon Valley check out the Elective Course link in the left menu for Managing Projects with Microsoft Project.    *** NOTE: Space is still available for the next class starting  Sat 9/19 ***

Coming up next time, a closer look at…  PMI and the PMP credential – why it’s finally time for many project managers to consider certification.

Thanks for reading.  Your comments are always welcome!

- Jim Park, PMP
Instructor, Project and Program Management certificate program
UCSC Extension in Silicon Valley

Technorati Tags: best-practices, Planning, PMO, Professional-Development, project-management-tools, resources, Tracking & control

With the kick-off of Project Conference 2009 in Phoenix, AZ this week Microsoft has invited some customers and partners to get a sneak peek at Microsoft Project 2010.  I have been managing projects and teaching classes on this tool for quite a long time and have had a chance to read about some of the latest ‘improvements.’  Unfortunately, this new release still does not address some basic needs for project managers as they approach the tool.  Here are some practical suggestions when using (any version of) Microsoft Project.

Understand the Challenges to Using MS Project – There’s a reason that spreadsheets are the most commonly used software tools to manage projects.  Spreadsheets are more intuitive and predictable than MS Project.  MS Project is relatively easy to use when starting to coordinate tasks but it can quickly become cumbersome and unmanageable when attempting to optimize resources and control your schedule or budget.  A streamlined approach to using the most appropriate features is highly recommended.  I have generally found that a project manager can effectively plan and control their projects with far less than half of the tool’s functionality.  One way to streamline your approach to the tool is to minimize data entry to certain key fields (e.g. Task Name, Predecessor, Duration, Actual Start, Actual Duration and Remaining Duration to name a few).

Know the Planning Limitations - Microsoft Project is not a project management tool.  Let me repeat that last sentence: Microsoft Project is not a project management tool.   It was developed as a schedule tracking application but has become accepted over the years as a comprehensive project management tool.  It is not the most effective tool when it comes to brainstorming activities like project planning.  Many project managers get challenged when they drag their teams through a planning session with nothing but a Gantt Chart.  Gantt Charts are not very conducive to team interaction during the planning process.  Teams often respond better and produce higher quality planning information when using affinity diagramming tools like mind maps and work breakdown structures.  That brings up another good suggestion…

Integrate a Work Breakdown Structure (WBS) – For all the years that Microsoft Project has been in use, there has never been a built-in WBS feature.  This has always amazed me.  Previous versions have attempted to integrate with Microsoft Visio to create WBS diagrams but this was never an effective feature.  Project managers will often utilize summary tasks and subtasks (i.e. indenting tasks) in order to create a hierarchy of work within a Gantt Chart.  This is a good start but I would go a step further and utilize an add-on tool such as WBS Chart Pro (criticaltools.com) which integrates the Work Breakdown Structure into MS Project for reporting as well as front-end planning functionality.

Improve Estimation Techniques – Often times the weakest link in the planning process is the quality of work and cost estimates for project activities.  There are several things to keep in mind as you enter Duration, Work or Cost estimates into MS Project.  First, it is your responsibility as the project manager to challenge and validate estimates you receive from various sources.  If you have gone through enough projects, you know that you cannot assume every estimate will be accurate.  Refer to historical data, break down components to smaller work packages and push back on those Subject Matter Experts (SMEs) until you are more confident in the quality of the estimates.  In addition, you can use various techniques such as Delphi to gain consensus on estimates or Stochastic Modeling to leverage three-point estimates and improve the confidence in your overall schedule or budget.  There are built-in PERT Analysis features, add-on tools (e.g. Risk+ from Deltek) and even macros for Monte Carlo simulation available to integrate three-point estimation and risk management into Microsoft Project plans.

Standardize, Share, and Optimize Your Resources – Entering resources in Microsoft Project is quite easy.  Defining them properly is not.  What I mean is that coming up with a standard naming convention for resources can be challenging.  This is especially true when there are many different stakeholders for project data – resource managers, executives, portfolio/program management and, of course, team members.   Defining a common set of resources to meet all major reporting needs is often the job for a Project Management Office (PMO).  The PMO may also be charged with setting up a Resource Pool which can be shared across multiple projects and maintained centrally.  Ultimately, a key project management responsibility during the planning and control portions of a project is to optimize the usage of resources such that those resources can effectively achieve the work and thereby commit to the plan.  A good understanding of the Resource Leveling feature in MS Project allows a project manager to identify key resource bottlenecks and optimize assignments proactively to reduce schedule risk.

Know Your Limitations in Sharing Information – It’s much easier to share information with spreadsheets than with MS Project since almost everyone has a spreadsheet application on their computer.  Unfortunately, licensing costs make MS Project a limited deployment for most organizations.  For the individual project manager there is a rarely leveraged discount available through academic licensing.  Taking a professional development course or having a child in school allows for up to 90% off of the list pricing.  It is well worth taking advantage of this discount.  Check out online academic software resellers for more information on eligibility and pricing.

For a more in-depth look at Microsoft Project Best Practices at UCSC Extension in Silicon Valley check out the Elective Course link in the left menu for Managing Projects with Microsoft Project.

Coming up next time, a closer look at… Limitations in Critical Path Methodology, Compressing Schedules Effectively, Achieving Consensus and Understanding Baselines, Controlling Projects by Variance Analysis and Supporting Multiple Project Managers.

Thanks for reading.  Your comments are always welcome!

- Jim Park, PMP
Instructor, Project and Program Management certificate program
UCSC Extension in Silicon Valley

Technorati Tags: best-practices, estimation, Planning, Professional-Development, project-management-tools, resources, wbs

photo by nutmeg66

My first two guest posts were about the intersection of Knowledge Management and Project Management; in this post I would like to talk about what I think are some of the peculiarities of Knowledge Management projects.

For the most part Knowledge Management projects are just like any other projects, tasks have to be delineated, risk managed, status reports given, you know the drill. What I think is different about knowledge management projects is that they tend to touch on more of the organization, often they are enterprise wide and no one wants to own them in part because they don’t understand them.

If an owner or owners are identified and a management change occurs it can throw the whole project into question. The success of the project often comes down to influence and sustained management support from one person at least for the first little while, until the business case is proven. Although even then I have seen successful projects shut-down because the new management team didn’t understand the value of the initiative.

There are often multiple stakeholders on both the business and IT side, with IT taking a lead. IT taking the lead is a problem. Technology is an enabler and a critical part of the project, but the project needs to be lead by the business. Technology ultimately needs to enable business processes, not be some extra “nice to have.” This only happens if business takes the lead and ensures that the technology is supporting business processes, not hampering them. When business leads they focus on the people and process part of the equation, and work to provide a balanced solution, not a technology-centric one.

The value of Knowledge Management is often hard to measure, in tangible ways. Connecting people to the knowledge they need to do their jobs is often described as an opportunity cost. How can I measure something if I don’t know the value of having it? For example, what if I “recreate the wheel” because I didn’t know a colleague in another region had already “created the wheel”? You never know you’ve recreated something, so can’t measure the cost/benefit.

One project I did was like that, a team in Asia-Pacific had found a solution to their ISO 9000 document management needs, it had taken them 6 months. Another team in North America was starting out on finding a solution to the same problem. I connected the two teams and the second one took 3 weeks to get their documentation sorted out because they could re-use what the first team had done. If the connection hadn’t been made, the second team could have taken six months or even longer to resolve the issue, but would never have known the difference.

Those are what I think are the main oddities about Knowledge Management projects, they aren’t reasons not to do them, just issues to be aware of and monitor closely throughout the project lifecycle.

photo by *spudballoo* via Flickr

It had all the earmarks of a disaster, a real career-sinker of a project. And here was my old friend and former colleague calling me up enthusiastically, on the phone: “Hey Lisa, we need a Technical Project Manager for this start-up I’m working for, in Redwood Shores… you’ll love the project and the team. It’s a fun environment and they treat consultants really well here – honestly.” Okay, Ted, what’s the kicker? “Oh, by the way, we’re short-staffed – you’ll have to code, just 20% of the time. It’s just lightweight GUI stuff; no big deal.”

“Ummm, Ted – I haven’t coded in over 6 years, that’s forever!” I moaned. “I’m a project manager now. Cannot do – seriously.” “Oh, you’ll be fine; I’ll show you the ropes – it’s like riding a bike,” he assured me.

Oh jeez. Well, you can guess – I was between gigs and it did sound intriguing. I had enjoyed working with Ted at Autodesk, and I thought, “How bad could it be?”

At any rate, after cramming on programming languages for two consecutive weekends and hosing one of my laptops (thank goodness it was a dinosaur), I showed up at the company. Ted was right, it was a great environment – just 32 people in the office and everyone was about the same age and at the same stage of life. We also had an office in Toronto and in London, making for 3 different development streams (counting Redwood Shores) that needed to be integrated in order to produce the company flagship product, a suite of software applications in the interactive TV space. All of the major customers were overseas in Europe and Asia.

So my major contribution was managing the overall program and pulling together an integrated schedule for Development, QA, etc…, controlling the budget, risk management, all the usual Project Management activities… and I also had to create the screens/UI for one of the applications.

I have to say that this was one of the most interesting and challenging contracts ever. I learned something new every day from the technical wizards, many of whom had worked at Oracle and Peoplesoft (they all went on to work at Yahoo and Google some years later.) By the end of the job, I was coding Oracle servlets with the best of them. It still remains as a high point in my career as a technologist.

But I digress…

What Ted hadn’t told me on the phone, and what I discovered a few weeks later into the project, was that the last Project Manager had quit – and not on good terms. He was “disgusted and frustrated with the state of affairs,” one of the developers told me. I soon found out why. We would have conference calls and the developers in Redwood Shores would sit around the conference table with their arms folded, feign listening politely, and make passive/aggressive comments. The folks in Toronto and London, on the other hand, talked up a storm, making jokes. For Mike and Tom, our lead developers in the U.S., the levity of the foreigners was just not funny – they had managed to lock the code branches they were working on, once again, so that the Redwood Shores team was unable to perform integration. What seemed on the face of it just some idle banter and typical team storming was becoming a real issue.

I decided to take the bull by the horns. I managed to get CFO approval to get the two non-domestic teams onto U.S. soil on a “Kumbayah Roadtrip,” as Ted put it – but I was betting the farm on the visit. I arranged for team-building activities, such as the now-famous “Trust” exercise of running and leaping into your teammates’ arms and trusting that they won’t let you fall. We went bowling and played miniature golf (yeah, I know, it’s corny), and had lots of working lunches and dinners. We even went to see a play at the Curran Theatre in San Francisco. Somehow, at the end of the ten days, we had managed to bond and get past both the cultural differences and the quirky personality traits – all three teams had finally started to function as one, which was critical to both project success as well as the corporate bottom line.

What happened during the Canadian and British teams’ visit was truly amazing. Mike and Tom were able to air out their frustration with the overall sloppiness and lack of protocol with the development processes, and the Canadians and British took their criticisms to heart. I did have to play referee and adopt a “Gentlemen, get into your corners” attitude, but it was well-worth the initial less than optimal discussion.

It’s easy to misunderstand and make communication faux pas while on the phone, and not in person. It’s a lot harder to ignore someone when they’re physically sitting across from you at the table… and your body language can give you away in a way that doesn’t happen over a telephone wire. And it’s definitely easier to dismiss and malign another team member’s efforts when you haven’t met them in person.

Project Managers can set the tone and help facilitate the tough discussions when they are needed. We can help smooth things over and remind folks not to take things so personally, and to try to pursue solutions as a team. Perhaps most significantly, we can provide real business value by working to build bridges and relationships between team members, and ensuring that the sum of the parts is greater than the whole so that the project is delivered on time, within budget.

Technorati Tags: attitude, Budget, communication, control, Corporate, criticism, Customer, Environment, integration, interest, joke, Language, Listening, management, people, PM, process, Relationships, Risk, schedule, Success, Team, Teambuilding, Teams, time, trust

via Flickr by wickedchimp

Every program manager has run into the same situation at some point in their career. You put together your program plan with lots of spreadsheets, Gantt charts, requirements documents, resource requirements, risk management plan, etc. You present the plan to management and everything goes reasonably well until you start to talk about risks and how to mitigate them.    We’ve all heard the same old arguments. Management says “Risk? What risk? We have the best and brightest people in the industry” and the team says anything we can’t control is a risk “What if someone quits in the middle of the project”. In my opinion, both extremes are wrong.

Why management is wrong: Seriously, new product development means that you are doing something that has not been done before (possibly in the world but at least in the company), which means that there are unknowns and unknown items equal risk. Of course the degree to which the project is truly revolutionary vs. evolutionary will impact the level of risk the program is exposed to. As for having the best and brightest people, if every company has the best and brightest then no company does.

Why the project team is wrong: Consider your audience. Management expects you and your team to do your job, which means they expect you to mange standard day to day “challenges”. Therefore, if you load your risk management plan up with issues like “resource conflicts might occur” they are simply going to say “tell me something I don’t know”.

What is the right way to address risk? There are many ways to address risks; this is what has worked for me. The simple truth is that you cannot account for every possible risk; if you did you would probably never get out of bed in the morning (of course that may increase the risk of being fired so you are forced to make a trade off). In other words, life is loaded with risk; that is the cost of living. Similarly, projects are full of risks, some will be acceptable (getting out of bed) and others will be unacceptable (getting fired). Focus your efforts on the unacceptable risks, the acceptable ones are the cost of doing business and it is your job to manage them on a day to day basis.

What to do? Address the unacceptable risks while acknowledging the acceptable risks and reevaluate the risks continuously throughout the life of the project. Here is my simplified view of risk identification and mitigation.

1) When putting your plan together it is always best to start at the beginning and define what success will look like. Don’t limit yourself to the traditional triple constraint of Schedule, Cost, and Resources. Consider the total product offering and the customer experience.

2) Once you have defined what success looks like you can put the development plan together (as a good friend once said “there’s nothing more frustrating than trying to solve a problem that hasn’t been defined”).

3) Now that you have your success criteria and development plan defined you can start addressing risks.

a. Develop a check list of risk areas to assess:

i.                 Schedule

ii.               Cost

iii.             Resources

iv.             Technology

v.               Manufacturing

vi.             Quality

vii.           Customer experience

viii.         Historical issues

b. Remove ambiguous language from your goals and specifications, there is nothing worse than a specification that can’t be verified. My personal favorite is when the system specification says the “system availability shall be the same as the previous product”. Of course the previous product says the same thing.

c. Work with your team to identify the risks along with the probability of occurrence and the potential hit. Remember, your team is filled with experts in each area of the program, take advantage of them.

d. Risk Impact: A simple way to look at this is to say the risk impact = Cost if the risk occurs x Probability of occurrence.

e. Determine if the risk is acceptable or unacceptable. Go back to your success criteria, if the impact of the risk does not prevent you from meeting one of your success criteria it is “acceptable”. However, if it causes a success criteria to be missed you need to make a decision; do I tweak the plan to account for this risk or do I identify it separately and ask to implement a mitigation plan either up front or at a future date when some trigger occurs.

4) Change the culture. Most companies reward people who make great saves on the project. Unfortunately, most of the time the people putting out the fires are the same people who caused the fire in the first place. If you change the culture to one where fire prevention is rewarded you will likely find there are significantly fewer “fires” on your programs.

5) Accelerators: Managing a program is like playing chess, the best players use all their pieces in concert with each other and sometimes sacrifice a piece to attain a greater objective. Projects are no different many tasks can be moved around to optimize overall performance so look at the positives, perhaps you can accelerate some tasks in order to allow more time for the really gnarly issues that will pop up later.

Summary: Risk is a part of anything worth doing, you take care of the acceptable ones and get management focused on supporting you on the unacceptable ones. When you present the risks put them in terms that management will appreciate, in other words what is the ROI for mitigating the problem. Finally, be sure to evaluate risks throughout the program, if you stick the risk management plan in the drawer you are sure to miss the biggest risks until they bite you!

egaeta@pacbell.net

Technorati Tags: best-practices, Conflict & issue management, Leadership, Planning, project-management, Risk

How about a entire organization being a control-freak?

I was working with a company that had had some projects go “totally out of control.”  By that they meant that they had exceeded costs by over 20%, missed “deadlines” by over 20%, and were not close to delivering with no visibility on when it might be done.

It was clear to the managers that they needed more controls.  “We need stricter controls to keep us on track.  What kind of reports do we need to make people more accountable?”  Well, as much as I could make a few bucks improving their control reports, I had a few doubts about how much improvement they would gain.

Poking around a bit on one of the projects, a few items popped up.

• Significant milestones were missed in the first 2 weeks of the project – these were not reflected in the official progress reports;
• More people were added to the project in the first 6 weeks;
• Some members were asked not to report hours;
• Customer requested more detailed status reports several times in the first 3 months;
• After one prototype demonstration, the customer made some requests that resulted in a significant disagreement regarding the contract.

Some things sound familiar?

Poking a bit more:

• The people building the deliverables were not allowed any direct contact with the customer because “this would be distracting them from their jobs;”
• There was a version of an Earned Value system in place — some managers spent more than 4 hours a week “tweaking” the inputs;
• “95% compliance” was the standard for performing to plan — individuals that did not attain this were not eligible for bonuses;

More control reports were not going to help much.  Now, I’m a big fan of tracking, but that is only part of the control system.  In a way, it’s the rear view mirror picture — how did we do in the past.  In this company, that rear view was the focus.  Also, there was the idea that punishing someone for “missing” the target was a major component of control — that’s what accountability is, right?

For these managers, control was an illusion, a myth.  For them, more control meant keeping track of more things, keeping a tighter reign, imposing more restrictions on judgment and replacing them with rules.

I’m going to suggest that control is a system where we monitor execution, compare performance to a baseline, assess root cause of significant deviations, and adjust in order to increase the probability of achieving project objectives.

In this company, it turned out that the baseline was flawed from the beginning, the system drove people to hide deviations as long as possible, and blame was the game.

Installing their Earned Value procedures, in the name of greater control, actually resulted in less control.  By focusing on the blaming side of accountability, it was in the best interest of project people to use the intricacies of the system to hide problems, not reveal them.

To be sure, there were lots of problems besides the control system — less than stellar client management, wishful thinking as policy, and rule-based command hierarchy among them.  But, since things had gotten so bad, we did get to make a few changes in the control process as a starting point for wider changes.

First, we temporarily disengaged the Earned Value process and used a simpler milestone and cost tracking method.  Second, we instituted Deviation Meetings — no blaming (that took some time to fully realize), and root cause techniques were learned and used.  We did not win all the battles and there was more than a bit of backsliding.  But we did win a few and fixed some things before they became big crises.  Then, we found and fixed more things.  Then, we were able to decrease our deviation tolerances and found more problems earlier, and more people were encouraged to bring up issues, and… then it got to be fun.

We had improved performance not with more rear-view controls, but by focusing on using the data in formulating go-forward strategies.

I like good controls that result in good performance.  Am I crazy, or are many companies suffering from too much “control?”

Alan Tsuda

Technorati Tags: control, Execution, illusion, myth